ISIS
Last updated
Last updated
All IPv4 and IPv6 addresses are configured. The IGP is not configured at all here, allowing you to practice configuring ISIS.
Enable ISIS according to the diagram. All routers in area 1 should be level-2-only. All routers in area 2 and 3 should be level-1 only, except for the ABRs which are L1/L2. Use an ISIS routing process called core on all routers. Ensure that no router is elected as a DIS anywhere in the topology.
Next, we will originate a default into ISIS on R10 and R11. But before doing that, which routers currently have a default route in their RIB in this topology? Moving on, originate a default on both R10 and R11, and do it in such a way that R10 is preferred for all outbound traffic, and R11 is only used as a backup default route.
Make R1’s routing table match this output:
Ensure ISIS is enabled on Lo1 on R1. Summarize these prefixes so that only a single route is seen in the L2 network.
Currently R6 reaches 10.7.8.8/24 via R3. Why is this? How can you change this so that R6 will use R8 as the nexthop for 10.7.8.0/24?
Adjust metrics on only two interfaces so that traffic between R1 and R3 is asymmetric. For example:
Redistribute the /32s from eBGP on R10 and R11. By default, what is the route-type for these routes as seen on R8? What about R1?
Redistribute eBGP on R3 so that R1 can ping R4.
Enable ISIS for IPv6 on all routers. R10 should be able to ping R1’s loopback of 2001:db8::1
Do you need metric-style wide when running IPv6?
What are the pros and cons of running multitopology and single-topology for IPv6?
If you want to run multitopology, which routers do you need to configure for multitopology explicitly: IOS-XE or IOS-XR?
See basic ISIS configuration guides if needing help with this.
All L1-only routers have a default in their RIB. An L1-only router installs a default to the nearest L1/L2 router (which is determined by lowest metric). An L1-only router knows a router is attached to the L2 via the attached bit in the LSP. In our topology, only R1 and R3 are L1-only routers. On R10 and R11 originate the default. In ISIS there is no always option, default-information originate will advertise a 0/0 even if it does not exist in the RIB. To make R11 the backup 0/0 route, you can set the default-information originate to use a route-map which sets the route-type as external, or simply set metric +10.
By default, a L1 area in ISIS works as a totally NSSA in OSPF. An L1/L2 router hides all inter-area routing information from the L1 area and simply uses the attached bit to signal default routing is available. You can leak L2 routes into the L1 by using the propagate command. In this case, you will need to reference a route-policy that permits only destinations matching 0.0.0.0/0 eq 32 so that you only see the loopbacks, and not the transit /24 subnets.
On the ABR, XR5, use the summary-prefix command.
This is because ISIS prefers L1 intra-area routes over L2 routes. XR7 by default uses L1/L2 on all interfaces, and therefore advertises Gi0/0/0/0 into the L1 area. By setting this interface to circuit-type level-2-only you can prevent it from being advertised into area 3 as an intra-area route. R6 will then use the L2 route towards R8 to reach that prefix.
Because a L1/L2 router hides the inter-area topology from L1 routers, you can simply adjust metrics to have an L1 router prefer a particular L1/L2 router for all default routing. In this case, we can set Gi2 or Gi3 for a metric higher than 10 in order to prefer R6 or XR7 for the default route. Next we need to have R8 prefer either R6 or XR7 to reach R3. You will need R8 to prefer whichever router is not being used by R3 as the default gateway. You can do this by also increasing the metric on Gi3 or Gi4 of R8. Once this is setup, R1 will take a path through R6 or XR7 to get to R3. And R3 will use the opposite L1/L2 router for default routing towards R1.
The route type is a normal L2 route on R8 and a normal IA route on R1. When you redistribute routes into ISIS they should up as just another prefix attached to the router, although in the LSP it is indicated as an External.
The reason for this is that the prefix is advertised in the External IP Reachability TLV and not the Internal IP Reachability TLV. However, IOS does not make a distinction between these two when the route is displayed in the RIB. Nevertheless, the fact that it is external is taken into account when choosing between an external route and an internal route. A router will prefer the internal route. When using wide-metrics, the external prefixes and internal prefixes are both carried in the Extended IP Reachability TLV and external prefixes are marked with a flag in a sub-TLV.
When redistributing routes into ISIS on a L1-only router you need to use the keyword level-1 on the redistribute command.
Simply enable ISIS for ipv6 on all interfaces and loopbacks. In IOS-XE you use ipv6 router isis core under the interface. In IOS-XR you activate the address-family under each individual interface. By default, IOS-XE uses single-topology and IOS-XR uses multitopology. You will need to decide which style to run and enable it on the respective devices. If using single-topology, you must enable this on IOS-XR routers only. If using multitopology, you must enable it on IOS-XE routers only. Multitopology requires the use of wide metrics, so you also must enable this on all routers if you enabled already. Single-topology can work with the default narrow metrics. Multitopology allows you to easily migrate from IPv4-only to a dual-stacked network with no downtime. However it requires wide metric support. Multitopology also allows you to engineer different paths for IPv4 and IPv6 prefixes, because each address family has its own independent topology. Multitopology uses more CPU due to more SPF runs, but this is negligible in today’s equipment. Single-topology requires every adjacency to support both IPv4 and IPv6 protocols in order to establish, which can create a headache when migrating IPv4 to dual-stack. Single-topology allows ISIS to use a single SPF run for both IPv4 and IPv6 routing, but doesn’t allow for any flexibility in terms of traffic engineering each protocol separately.
