The IP header of the EIGRP packet specifies IP protocol number 88 within
it, and the maximum length of the packet will be the IP MTU of the
interface on which it is transmitted, most of the time 1500
octets. Following the IP header is the various Type/Length/Value (TLV)
triplets. These TLVs will not only carry the route entries but also
provide fields for the management of the DUAL process, multicast
sequencing, and IOS software versions from the router.
EIGRP sends updates and other information between routers using multicast packets to
224.0.0.10. For example in the topology below, R1 made a change in the topology and it
needs to send updates to R2 & R3. It sends multicast packets to EIGRP multicast address
224.0.0.10. Both R2 & R3 can receive the updates and acknowledge back to R1 using
unicast. Simple, right?
But what if R1 sends out updates, only R2 replies but R3 never does? In the case a router
sends out a multicast packet that must be reliable delivered (like in this case), an EIGRP
process will wait until the RTO (retransmission timeout) period has passed before
beginning a recovery action. This period is calculated from the SRTT (smooth round-trip
time). After R1 sends out updates it will wait for this period to expire. Then it makes a list of
all the neighbors from which it did not receive an Acknowledgement (ACK). Next it sends
out a packet telling these routers stop listening to multicast until they are been notified that
it is safe again. Finally the router will begin sending unicast packets with the information to
the routers that didn’t answer, continuing until they are caught up. In our example the
process will be like this:
1. R1 sends out updates to 224.0.0.10
2. R2 responds but R3 does not
3. R1 waits for the RTO period to expire
4. R1 then sends out an unreliable-multicast packet, called a sequence TLV (Type-Length-
Value) packet, which tells R3 not to listen to multicast packets any more
5. R1 continues sending any other muticast traffic it has and delivering all traffic, using
unicast to R3, until it acknowledges all the packets
6. Once R3 has caught up, R1 will send another sequence TLV, telling R3 to begin
listening to multicast again.
The sequence TLV packet contains a list of the nodes that should not listen to multicast
packets while the recovery takes place. But notice that the TLV packet in step 6 does not
contain any nodes in the list.
Note. In the case R3 still does not reply in step 4, R1 will attempt to retransmit the unicast
16 times or continue to retransmit until the hold time for the neighbor in question expires.
After this time, R1 will declare a retransmission limit exceeded error and will reset the
neighbor.
Tuesday 22 March 2016
OSPF P bit
When external routing information is imported into an NSSA, LSA Type 7 is generated by
the ASBR and it is flooded within that area only. To further distribute the external
information, type 7 LSA is translated into type 5 LSA at the NSSA border. The P-bit in LSA
Type 7 field indicates whether the type 7 LSA should be translated. This P-bit is
automatically set by the NSSA ABR (also the Forwarding Address (FA) is copied from Type
7 LSA). The P-bit is not set only when the NSSA ASBR and NSSA ABR are the same
router for the area. If bit P = 0, then the NSSA ABR must not translate this LSA into Type 5.
The nssa-only keyword instructs the device to instigate Type-7 LSA with cleared P-bit,
thereby, preventing LSA translation to Type 5 on NSSA ABR device.
Note. If a router is attached to another AS and is also an NSSA ABR, it may originate a
both a type-5 and a type-7 LSA for the same network. The type-5 LSA will be flooded to the
backbone and the type-7 will be flooded into the NSSA. If this is the case, the P-bit must be
reset (P=0) in the type-7 LSA so the type-7 LSA isn’t again translated into a type-5 LSA by
another NSSA ABR.
the ASBR and it is flooded within that area only. To further distribute the external
information, type 7 LSA is translated into type 5 LSA at the NSSA border. The P-bit in LSA
Type 7 field indicates whether the type 7 LSA should be translated. This P-bit is
automatically set by the NSSA ABR (also the Forwarding Address (FA) is copied from Type
7 LSA). The P-bit is not set only when the NSSA ASBR and NSSA ABR are the same
router for the area. If bit P = 0, then the NSSA ABR must not translate this LSA into Type 5.
The nssa-only keyword instructs the device to instigate Type-7 LSA with cleared P-bit,
thereby, preventing LSA translation to Type 5 on NSSA ABR device.
Note. If a router is attached to another AS and is also an NSSA ABR, it may originate a
both a type-5 and a type-7 LSA for the same network. The type-5 LSA will be flooded to the
backbone and the type-7 will be flooded into the NSSA. If this is the case, the P-bit must be
reset (P=0) in the type-7 LSA so the type-7 LSA isn’t again translated into a type-5 LSA by
another NSSA ABR.
ISIS
reference thanks to https://mellowd.co.uk/ccie/?p=5487
This is the topology we’ll start with:
Like OSPF, IS-IS will treat ethernet links as broadcast by default. In OSPF a DR and BDR will be elected. In IS-IS a single DIS (Designated Intermediate System) is elected with no backup DIS. This DIS election is also pre-emtptive, unlike OSPF. The DIS will originate an LSP representing the DIS. This means I should have three LSPs in the database currently:
It’s important to note that an LSP is made up of several TLVs. On the wire multiple TLVs can be grouped together in a single frame. If large enough, IS-IS will fragment these frames.
As XR1 is the DIS, there is a separate DIS LSP, let’s take a look at that:
If I change the segment to point-to-point, this removes the need of a DIS and as such there will be no DIS LSP.
the R2-R3 link has not been changed to point-to-point, and as such I would expect to see three LSPs in XR3s database:
For now I’ve added an IPv6 loopback and interface address. I’ve got IS-IS running in multi topology mode. I should still only see two LSPs from XR1’s perspective:
Basic LSPs
In OSPF we use the term LSA, Link-State Advertisement. In IS-IS we use the term LSP – Link-State PDUs. Further expanded into Link-State Protocol Data Units. Not to be confused with Label Switched Paths.This is the topology we’ll start with:
Like OSPF, IS-IS will treat ethernet links as broadcast by default. In OSPF a DR and BDR will be elected. In IS-IS a single DIS (Designated Intermediate System) is elected with no backup DIS. This DIS election is also pre-emtptive, unlike OSPF. The DIS will originate an LSP representing the DIS. This means I should have three LSPs in the database currently:
RP/0/0/CPU0:XR1#show isis database Tue Aug 12 17:34:21.594 UTC IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL XR1.00-00 * 0x00000003 0x8577 736 0/0/0 XR1.01-00 0x00000002 0x1fba 931 0/0/0 XR2.00-00 0x00000005 0x856b 806 0/0/0 Total Level-2 LSP count: 3 Local Level-2 LSP count: 1XR2 has a single LSP with XR1 has two. The XR1.01 LSP is the DIS LSP. Dig deeper into the LSPs to see their current content:
RP/0/0/CPU0:XR1#show isis database XR1.00-00 detail Tue Wed 12 17:38:23.307 UTC IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL XR1.00-00 * 0x00000003 0x8577 494 0/0/0 Area Address: 49.0001 NLPID: 0xcc Hostname: XR1 IP Address: 1.1.1.1 Metric: 10 IS XR1.01 Metric: 10 IP 1.1.1.1/32 Metric: 10 IP 10.0.12.0/24XR1 has originated an LSP stating what area it’s in and hostname. Notice the NLPID value. This means Network Layer Protocol IDentifier. The value of 0xcc translates to IPv4. Further down the LSP contains the IS of XR1 itself, plus two IP ranges. All these with metrics to those IS and IPs. I’ll get onto the ATT/P/OL bits later so ignore those for now.
It’s important to note that an LSP is made up of several TLVs. On the wire multiple TLVs can be grouped together in a single frame. If large enough, IS-IS will fragment these frames.
As XR1 is the DIS, there is a separate DIS LSP, let’s take a look at that:
RP/0/0/CPU0:XR1#show isis database XR1.01-00 detail Tue Aug 12 17:43:00.448 UTC IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL XR1.01-00 0x00000003 0x1dbb 1161 0/0/0 Metric: 0 IS XR1.00 Metric: 0 IS XR2.00The DIS LSP advertises all the IS’ that are on the segment in which the DIS sits.
If I change the segment to point-to-point, this removes the need of a DIS and as such there will be no DIS LSP.
router isis 1 ! interface GigabitEthernet0/0/0/1 point-to-point
RP/0/0/CPU0:XR1#show isis database Tue Aug 12 18:46:50.566 UTC IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL XR1.00-00 * 0x0000000b 0x7480 674 0/0/0 XR2.00-00 0x0000000d 0x5297 543 0/0/0 Total Level-2 LSP count: 2 Local Level-2 LSP count: 1
Externals
I’m going to add another loopback interface on XR1 and redistribute that loopback into IS-IS. This will make the route externalinterface Loopback100
ipv4 address 100.100.100.100 255.255.255.255
!
prefix-set LOOPBACK100
100.100.100.100/32
end-set
!
route-policy RP-100
if destination in LOOPBACK100 then
done
else
drop
endif
end-policy
!
router isis 1
address-family ipv4 unicast
redistribute connected level-2 route-policy RP-100
As I mentioned above, IS-IS has separate TLVs that make up the LSP. Therefore there is still only a single LSP from XR1:RP/0/0/CPU0:XR2#sh isis database Tue Aug 12 19:03:31.569 UTC IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL XR1.00-00 0x0000000d 0x6be5 1043 0/0/0 XR2.00-00 * 0x00000010 0x9c8f 1094 0/0/0 Total Level-2 LSP count: 2 Local Level-2 LSP count: 1The external route can be seen in the detailed output under that LSP:
RP/0/0/CPU0:XR2#sh isis database XR1.00-00 detail Tue Aug 12 19:03:58.637 UTC IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL XR1.00-00 0x0000000d 0x6be5 1016 0/0/0 Area Address: 49.0001 NLPID: 0xcc Hostname: XR1 IP Address: 1.1.1.1 Metric: 10 IS XR2.00 Metric: 10 IP 1.1.1.1/32 Metric: 10 IP 10.0.12.0/24 Metric: 0 IP-External 100.100.100.100/32
Inter-Area
XR3 has now been added to the topology. I’ve had to move XR2 into the same area as XR3 otherwise they will not be able to form a L1 adjacency:the R2-R3 link has not been changed to point-to-point, and as such I would expect to see three LSPs in XR3s database:
RP/0/0/CPU0:XR3#show isis database Tue Aug 12 09:44:40.660 UTC IS-IS 1 (Level-1) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL XR2.00-00 0x00000008 0xd230 1107 1/0/0 XR3.00-00 * 0x00000008 0xf1be 1105 0/0/0 XR3.07-00 0x00000003 0xfcd3 1105 0/0/0 Total Level-1 LSP count: 3 Local Level-1 LSP count: 1If you look at XR2’s L1 LSP in detail you now see the ATT bit set. Also note it’s advertising only it’s directly connected interfaces:
RP/0/0/CPU0:XR3#show isis database XR2.00-00 detail Tue Aug 12 19:45:51.025 UTC IS-IS 1 (Level-1) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL XR2.00-00 0x00000008 0xd230 1037 1/0/0 Area Address: 49.0023 NLPID: 0xcc Hostname: XR2 IP Address: 2.2.2.2 Metric: 10 IS XR3.07 Metric: 10 IP 2.2.2.2/32 Metric: 10 IP 10.0.12.0/24 Metric: 10 IP 10.0.23.0/24XR2 has set the ATT bit which is the attached bit. An L1/L2 router will set this bit in the LSP inside the L1 area it’s connected to. This is to inform the L1 routers that it is attached to the L2 domain. No actual default route is advertised, but L1 routers can create their own defaults pointing towards the attached routers:
RP/0/0/CPU0:XR3#sh ip route 0.0.0.0
Tue Aug 12 19:47:07.839 UTC
Routing entry for 0.0.0.0/0
Known via "isis 1", distance 115, metric 10, candidate default path, type level-1
Installed Aug 12 19:43:09.476 for 00:03:58
Routing Descriptor Blocks
10.0.23.2, from 2.2.2.2, via GigabitEthernet0/0/0/0.23
Route metric is 10
No advertising protos.
Notice from XR1’s persepctive, that any routes coming from an L1 area is simple flooded from the L1/L2 router as normal routes:RP/0/0/CPU0:XR1#show isis database XR2.00-00 detail Tue Aug 12 19:50:08.676 UTC IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL XR2.00-00 0x0000001b 0x5b3d 778 0/0/0 Area Address: 49.0023 NLPID: 0xcc Hostname: XR2 IP Address: 2.2.2.2 Metric: 10 IS XR1.00 Metric: 10 IP 2.2.2.2/32 Metric: 20 IP 3.3.3.3/32 Metric: 10 IP 10.0.12.0/24 Metric: 10 IP 10.0.23.0/24 Metric: 10 IP 200.200.200.200/32IS-IS gives you the ability to leak L2 prefixes into the L1 domain. This is handy when you have two L1/L2 border routers and want to engineer destiations to go on particular paths. From XR2 I’ll leak XR1’s loopback into the L1 domain. The database now shows:
RP/0/0/CPU0:XR3#show isis database XR2.00-00 detail Tue Aug 12 21:53:13.981 UTC IS-IS 1 (Level-1) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL XR2.00-00 0x0000002f 0x4e13 1193 1/0/0 Area Address: 49.0023 NLPID: 0xcc Hostname: XR2 IP Address: 2.2.2.2 Router Cap: 2.2.2.2, D:0, S:0 Metric: 10 IS XR3.07 Metric: 20 IP-Interarea 1.1.1.1/32 Metric: 10 IP 2.2.2.2/32 Metric: 10 IP 10.0.23.0/241.1.1.1/32 shows up in LSP as an IP-Interarea route. Again a TLV is used for this.
IPv6
When running both IPv4 and IPv6 at the same time, IS-IS can be run in single-topology or multi-topolgy mode. In single topology, all your IS-IS links need to have both v4 and v6 addresses as the SPF tree is run indenpently of prefix information. If the SPF tree is calculated to use a link without a v6 address, IPv6 traffic will be blackholed over that link.For now I’ve added an IPv6 loopback and interface address. I’ve got IS-IS running in multi topology mode. I should still only see two LSPs from XR1’s perspective:
RP/0/0/CPU0:XR1#show isis database Tue Aug 12 23:47:02.152 UTC IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL XR1.00-00 * 0x0000001e 0x9683 1115 0/0/0 XR2.00-00 0x0000002b 0x62fa 1117 0/0/0 Total Level-2 LSP count: 2 Local Level-2 LSP count: 1IPv6 information is carried inside another TLV. Note also that there is a new NLPID value of 0x8e in the LSP. As you would guess this value represents IPv6:
RP/0/0/CPU0:XR1#show isis database detail XR2.00-00 Tue Aug 12 23:47:50.899 UTC IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL XR2.00-00 0x0000002b 0x62fa 1068 0/0/0 Area Address: 49.0023 NLPID: 0xcc NLPID: 0x8e MT: Standard (IPv4 Unicast) MT: IPv6 Unicast 0/0/0 Hostname: XR2 IP Address: 2.2.2.2 IPv6 Address: 2001:db8:2:2::2 Metric: 10 IS XR1.00 Metric: 10 IP 2.2.2.2/32 Metric: 20 IP 3.3.3.3/32 Metric: 10 IP 10.0.12.0/24 Metric: 10 IP 10.0.23.0/24 Metric: 10 IP 200.200.200.200/32 Metric: 10 MT (IPv6 Unicast) IS-Extended XR1.00 Metric: 10 MT (IPv6 Unicast) IPv6 2001:db8:2:2::2/128 Metric: 10 MT (IPv6 Unicast) IPv6 2001:db8:12::/64When running multi-topology mode, you’ll see MT: plus the address families configured for multi-topology. If I change this to single topology:
RP/0/0/CPU0:XR1#show isis database XR2.00-00 detail Tue Aug 12 23:11:20.989 UTC IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL XR2.00-00 0x00000023 0xd22a 1196 0/0/0 Area Address: 49.0023 NLPID: 0xcc NLPID: 0x8e Hostname: XR2 IP Address: 2.2.2.2 IPv6 Address: 2001:db8:2:2::2 Metric: 10 IS XR1.00 Metric: 10 IP 2.2.2.2/32 Metric: 10 IP 10.0.12.0/24 Metric: 10 IP 10.0.23.0/24 Metric: 10 IP 200.200.200.200/32 Metric: 10 IPv6 2001:db8:2:2::2/128 Metric: 10 IPv6 2001:db8:12::/64MT no longer shows up, and all TLVs are added as-is to the LSP.
Traffic Engineering
To enable TE, wide-metrics need to be enabled. Up until this point I’ve been using narrow metrics. Once enabled You can see the TE information in the LSP by doing a verbose output:RP/0/0/CPU0:XR1#show isis database verbose XR2.00-00
Tue Aug 12 23:42:09.932 UTC
IS-IS 1 (Level-2) Link State Database
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
XR2.00-00 0x00000026 0x2dd8 910 0/0/0
Area Address: 49.0023
NLPID: 0xcc
NLPID: 0x8e
Hostname: XR2
IP Address: 2.2.2.2
IPv6 Address: 2001:db8:2:2::2
Router ID: 2.2.2.2
Metric: 10 IS-Extended XR1.00
Affinity: 0x00000000
Interface IP Address: 10.0.12.2
Neighbor IP Address: 10.0.12.1
Physical BW: 1000000 kbits/sec
Reservable Global pool BW: 0 kbits/sec
Global Pool BW Unreserved:
[0]: 0 kbits/sec [1]: 0 kbits/sec
[2]: 0 kbits/sec [3]: 0 kbits/sec
[4]: 0 kbits/sec [5]: 0 kbits/sec
[6]: 0 kbits/sec [7]: 0 kbits/sec
Admin. Weight: 167772160
Ext Admin Group: Length: 32
0x00000000 0x00000000
0x00000000 0x00000000
0x00000000 0x00000000
0x00000000 0x00000000
Metric: 10 IP-Extended 2.2.2.2/32
Metric: 10 IP-Extended 10.0.12.0/24
Metric: 10 IP-Extended 10.0.23.0/24
Metric: 10 IP-Extended 200.200.200.200/32
Metric: 10 IPv6 2001:db8:2:2::2/128
Metric: 10 IPv6 2001:db8:12::/64
Notice there there is no new NLPID value for TE. TE extensions are
enabled under address-family ipv4 and hence it uses the 0xcc id. If/when
RSVP-TE can use IPv6 natively, I could expect to see only the IPv6 ID.Overload
IS-IS has the ability to set the overload bit in an LSP. This could be originated by the router itself if it was overwhelmed, but it can also be hard set when doing planned works for example. If the overload bit is set, other routers will route around the router.router isis 1 set-overload-bitNote that OL bit set in the LSP:
RP/0/0/CPU0:XR1#show isis database Tue Aug 12 23:32:58.107 UTC IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL XR1.00-00 * 0x0000001f 0x9484 947 0/0/0 XR2.00-00 0x0000002e 0x97a4 1151 0/0/1 Total Level-2 LSP count: 2 Local Level-2 LSP count: 1I no longer have access to R3 now as R2 is the only router connecting these two devices:
RP/0/0/CPU0:XR1#ping 3.3.3.3 Tue Aug 12 23:08:44.083 UTC Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds: UUUUU Success rate is 0 percent (0/5)I am still able to ping XR2 itself though:
RP/0/0/CPU0:XR1#ping 2.2.2.2 Tue Aug 12 23:09:32.870 UTC Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 msWe’ve now seen the purpose of both the ATT and OL bits, so what is the P bit for? that bit is for the Partition Repair Bit which no vendor has implemented. i.e. it should always show 0.
Segment Routing
IS-IS is easily extended using new TLVs. If I enable segment routing under my IS-IS process, I see it added as a new TLV in the LSP:RP/0/0/CPU0:XR1#show isis database verbose XR2.00-00
Tue Aug 12 23:50:35.855 UTC
IS-IS 1 (Level-2) Link State Database
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
XR2.00-00 0x00000036 0x252b 954 0/0/0
Area Address: 49.0023
NLPID: 0xcc
NLPID: 0x8e
MT: Standard (IPv4 Unicast)
MT: IPv6 Unicast 0/0/0
Hostname: XR2
IP Address: 2.2.2.2
IPv6 Address: 2001:db8:2:2::2
Router Cap: 2.2.2.2, D:0, S:0
Segment Routing: I:1 V:0, SRGB Base: 900000 Range: 65535
Metric: 10 IS XR1.00
Metric: 10 IP 2.2.2.2/32
Metric: 20 IP 3.3.3.3/32
Metric: 10 IP 10.0.12.0/24
Metric: 10 IP 10.0.23.0/24
Metric: 10 IP 200.200.200.200/32
Metric: 10 MT (IPv6 Unicast) IS-Extended XR1.00
Metric: 10 MT (IPv6 Unicast) IPv6 2001:db8:2:2::2/128
Metric: 10 MT (IPv6 Unicast) IPv6 2001:db8:12::/64
ISIS Multitopology and single Topology
When working with IPv6 prefixes in IS-IS, you can configure IS-IS to be in a single topology for both IPv4 and IPv6
or to run different topologies for IPv4 and IPv6.
For now I’ve added an IPv6 loopback and interface address. I’ve got IS-IS running in multi topology mode. I should still only see two LSPs from XR1’s perspective:
IPv6
When running both IPv4 and IPv6 at the same time, IS-IS can be run in single-topology or multi-topolgy mode. In single topology, all your IS-IS links need to have both v4 and v6 addresses as the SPF tree is run indenpently of prefix information. If the SPF tree is calculated to use a link without a v6 address, IPv6 traffic will be blackholed over that link.For now I’ve added an IPv6 loopback and interface address. I’ve got IS-IS running in multi topology mode. I should still only see two LSPs from XR1’s perspective:
RP/0/0/CPU0:XR1#show isis database Tue Aug 12 23:47:02.152 UTC IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL XR1.00-00 * 0x0000001e 0x9683 1115 0/0/0 XR2.00-00 0x0000002b 0x62fa 1117 0/0/0 Total Level-2 LSP count: 2 Local Level-2 LSP count: 1IPv6 information is carried inside another TLV. Note also that there is a new NLPID value of 0x8e in the LSP. As you would guess this value represents IPv6:
RP/0/0/CPU0:XR1#show isis database detail XR2.00-00 Tue Aug 12 23:47:50.899 UTC IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL XR2.00-00 0x0000002b 0x62fa 1068 0/0/0 Area Address: 49.0023 NLPID: 0xcc NLPID: 0x8e MT: Standard (IPv4 Unicast) MT: IPv6 Unicast 0/0/0 Hostname: XR2 IP Address: 2.2.2.2 IPv6 Address: 2001:db8:2:2::2 Metric: 10 IS XR1.00 Metric: 10 IP 2.2.2.2/32 Metric: 20 IP 3.3.3.3/32 Metric: 10 IP 10.0.12.0/24 Metric: 10 IP 10.0.23.0/24 Metric: 10 IP 200.200.200.200/32 Metric: 10 MT (IPv6 Unicast) IS-Extended XR1.00 Metric: 10 MT (IPv6 Unicast) IPv6 2001:db8:2:2::2/128 Metric: 10 MT (IPv6 Unicast) IPv6 2001:db8:12::/64When running multi-topology mode, you’ll see MT: plus the address families configured for multi-topology. If I change this to single topology:
RP/0/0/CPU0:XR1#show isis database XR2.00-00 detail Tue Aug 12 23:11:20.989 UTC IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL XR2.00-00 0x00000023 0xd22a 1196 0/0/0 Area Address: 49.0023 NLPID: 0xcc NLPID: 0x8e Hostname: XR2 IP Address: 2.2.2.2 IPv6 Address: 2001:db8:2:2::2 Metric: 10 IS XR1.00 Metric: 10 IP 2.2.2.2/32 Metric: 10 IP 10.0.12.0/24 Metric: 10 IP 10.0.23.0/24 Metric: 10 IP 200.200.200.200/32 Metric: 10 IPv6 2001:db8:2:2::2/128 Metric: 10 IPv6 2001:db8:12::/64MT no longer shows up, and all TLVs are added as-is to the LSP.
First of all, let’s see how IS-IS works by default when activating IPv6. The lab I’m going to use is as follows:
By default, IS-IS works in single-topology mode when activating IPv4 and IPv6. This means that the IS-IS topology will be built based on IS Reachability TLVs. When the base topology is built, then IPv4 prefixes (IP Reachability TLV) and IPv6 prefixes (IPv6 Reachability TLV) are added to each node as leaves, without checking if there is IPv6 connectivity between nodes.
Let’s imagine we have the above IPv4 and IPv6 address scheme. As we can see, adjacencies are formed regardless the IP scheme on the link:
As we can see, the IS-IS IPv4 topology is built (IS Reachability TLV), and IPv4 and IPv6 prefixes are added to each node based on the information announced by each router (IP Reachability TLV and IPv6 Reachability TLV).
IS-IS doesn’t check the IPv6 consistency in the actual topology, so we
may come to the scenario where R5 thinks there is IPv6 connectivity to
reach R1 IPv6 address, when indeed, there isn’t:
What can we do to avoid this behaviour? We can activate IS-IS
Multitopology. Doing so, IS-IS creates two different topologies: one
built based on IS Reachability TLVs and dedicated to IPv4 routing info, and a second one built based on Multitopology IS Reachability TLVs and dedicated to IPv6 routing info.
Having two different topologies, now IS-IS can add IPv4 prefixes and
IPv6 prefixes to the correspondent node depending on the topology.
Because in the IPv6 topology there is no connectivity between R1 and R4,
the IPv6 info is consistent, and we can see that R4 and R5 doesn’t see
R1 and R2 IPv6 prefixes as reachable:
Of course, having two topologies increases the resources needed by
each router, and also the runs twice the spf algorithm, since you need
to keep two topology bases.
So all these make me think that a single-topology architecture is thought for dual-stack networks, where there is IPv4 and IPv6 connectivity end to end. While multitopology is for those scenarios where there may be some segments where IPv6 connectivity is not granted.
Let’s imagine we have the above IPv4 and IPv6 address scheme. As we can see, adjacencies are formed regardless the IP scheme on the link:
R4# show isis neighbors System Id Type Interface IP Address State Holdtime Circuit Id R1 L1 Fa1/0 10.10.14.1 UP 24 R4.01 R1 L2 Fa1/0 10.10.14.1 UP 29 R4.01 R5 L1 Fa2/0 10.10.45.5 UP 9 R5.01 R5 L2 Fa2/0 10.10.45.5 UP 9 R5.01 R4# show isis ipv6 topology R4# R4# show isis topology IS-IS TID 0 paths to level-1 routers System Id Metric Next-Hop Interface SNPA R1 10 R1 Fa1/0 ca00.0f26.0038 R2 20 R1 Fa1/0 ca00.0f26.0038 R4 -- R5 10 R5 Fa2/0 ca04.0f5d.001c IS-IS TID 0 paths to level-2 routers System Id Metric Next-Hop Interface SNPA R1 10 R1 Fa1/0 ca00.0f26.0038 R2 20 R1 Fa1/0 ca00.0f26.0038 R4 -- R5 10 R5 Fa2/0 ca04.0f5d.001cR4#
R5# show isis neighbors System Id Type Interface IP Address State Holdtime Circuit Id R4 L1 Fa1/0 10.10.45.4 UP 24 R5.01 R4 L2 Fa1/0 10.10.45.4 UP 28 R5.01 R5# show isis ipv6 topology R5# R5# show isis topology IS-IS TID 0 paths to level-1 routers System Id Metric Next-Hop Interface SNPA R1 20 R4 Fa1/0 ca03.0f3b.0038 R2 30 R4 Fa1/0 ca03.0f3b.0038 R4 10 R4 Fa1/0 ca03.0f3b.0038 R5 -- IS-IS TID 0 paths to level-2 routers System Id Metric Next-Hop Interface SNPA R1 20 R4 Fa1/0 ca03.0f3b.0038 R2 30 R4 Fa1/0 ca03.0f3b.0038 R4 10 R4 Fa1/0 ca03.0f3b.0038 R5 --
R5#
R5# sh ipv6 route
....
I1 2001:CC1E:1:1::1/128 [115/20]
via FE80::C803:FFF:FE3B:38, FastEthernet1/0
I1 2001:CC1E:2:2::2/128 [115/30]
via FE80::C803:FFF:FE3B:38, FastEthernet1/0
I1 2001:CC1E:4:4::4/128 [115/10]
via FE80::C803:FFF:FE3B:38, FastEthernet1/0
LC 2001:CC1E:5:5::5/128 [0/0]
via Loopback0, receive
...
R5# ping ipv6 2001:CC1E:1:1::1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:CC1E:1:1::1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) R5# R5# ping ipv6 2001:cc1e:4:4::4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:CC1E:4:4::4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/16/32 ms
(in each router) router isis net 49.0001.0050.0500.5005.00 metric-style wide passive-interface Loopback0 ! address-family ipv6 multi-topology exit-address-family
R5# show isis topology IS-IS TID 0 paths to level-1 routers System Id Metric Next-Hop Interface SNPA R1 20 R4 Fa1/0 ca03.0f3b.0038 R2 30 R4 Fa1/0 ca03.0f3b.0038 R4 10 R4 Fa1/0 ca03.0f3b.0038 R5 -- IS-IS TID 0 paths to level-2 routers System Id Metric Next-Hop Interface SNPA R1 20 R4 Fa1/0 ca03.0f3b.0038 R2 30 R4 Fa1/0 ca03.0f3b.0038 R4 10 R4 Fa1/0 ca03.0f3b.0038 R5 -- R5# show isis ipv6 topology IS-IS TID 2 paths to level-1 routers System Id Metric Next-Hop Interface SNPA R1 ** R2 ** R4 10 R4 Fa1/0 ca03.0f3b.0038 R5 -- IS-IS TID 2 paths to level-2 routers System Id Metric Next-Hop Interface SNPA R1 ** R2 ** R4 10 R4 Fa1/0 ca03.0f3b.0038 R5 --
R5# show ipv6 route
...
I1 2001:CC1E:4:4::4/128 [115/10]
via FE80::C803:FFF:FE3B:38, FastEthernet1/0
LC 2001:CC1E:5:5::5/128 [0/0]
via Loopback0, receive
...
R5# ping 2001:cc1e:4:4::4 sour lo0 Packet sent with a source address of 2001:CC1E:5:5::5 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/10/20 ms
So all these make me think that a single-topology architecture is thought for dual-stack networks, where there is IPv4 and IPv6 connectivity end to end. While multitopology is for those scenarios where there may be some segments where IPv6 connectivity is not granted.
BGP additional path
Information About BGP Additional Paths
Overview
BGP routers and
route reflectors (RRs) propagate only their best paths over their
sessions. The advertisement of a prefix replaces the previous
announcement of that prefix (this behavior is known as an implicit
withdraw). The implicit withdraw can achieve better scaling, but at the
cost of path diversity.
Path hiding can
prevent efficient use of BGP multipath, prevent hitless planned
maintenance, and lead to multi-exit discriminator (MED) oscillations and
suboptimal hot-potato routing. In a next-hop failure, path hiding
inhibits fast and local recovery because the network has to wait for BGP
control plane convergence to restore traffic. The BGP Additional Paths
feature offers path diversity; the best external or best internal
features offer path diversity in limited scenarios.
Path-Hiding Scenario
The following
figure shows prefix p with paths p1 and p2 advertised from BR1 and BR4
to RR1. RR1 selects the bes tpath of the two and then advertises only p1
to the PE.
In the above
figure, prefix x with path x1 is advertised from BR2 to BR3 (which has
path x2) with local preference 100. BR3 also has path x2, but due to the
routing policy, BR3 advertises to the RRs x1 (not shown) instead of x2,
x2 is suppressed. You could turn on the advertisement of best external
on BR3 and advertise x2 to the route reflectors (RRs), but, the RRs
advertise only the best path.
Suboptimal Hot-Potato Routing Scenario
To minimize
internal transport costs, transit Internet service providers try to
forward packets to the closest exit point (according to the Interior
Gateway Protocol (IGP) cost). This behavior is known as hot-potato
routing. In the distributed RR cluster model of the figure below, assume
traffic that is coming from LA must go to Mexico. All links have the
same IGP cost. If there are two exit points toward Mexico—one toward
Austin and one toward Atlanta—the border router will try to send traffic
to Austin based on the lower IGP cost from LA toward Austin than toward
Atlanta. In a centralized RR model where the central RR resides where
RR3 is (and RR1, RR2, RR4, and RR5 do not exist), the closest exit point
toward Mexico, as seen from RR3, might be Atlanta. Sending the traffic
from LA toward the Atlanta border router (BR) results in suboptimal
hot-potato routing and is not desirable.
Benefits of Additional BGP Paths
BGP routers and
route reflectors (RR) propagate only their best path over their
sessions. The advertisement of a prefix replaces the previous
announcement of that prefix (also known as an implicit withdraw).
While this behavior
might achieve better scaling, it can prevent path diversity, which
tends to be poor or completely lost. This behavior prevents efficient
use of the BGP multipath, prevents hitless planned maintenance, and lead
to multi-exit discriminator (MED) oscillations and suboptimal
hot-potato routing. It also inhibits fast and local recovery for
next-hop failures, because the network has to wait for BGP control plane
convergence to restore traffic.
BGP Additional Paths Functionality
You can use the BGP
Additional Paths feature by adding a path identifier to each path in
the Network Layer Reachability Information (NLRI). The path identifier
(ID) can be considered as something similar to a route distinguisher
(RD) in virtual private networks (VPNs), except that a path ID can apply
to any address family. Path IDs are unique to a peering session and are
generated for each network. The path identifier is used to prevent a
route announcement from implicitly withdrawing the previous one. The
Additional Paths feature allows the advertisement of more paths, in
addition to the best path and allows the advertisement of multiple paths
for the same prefix, without the new paths implicitly replacing any
previous paths.
1.
Specify whether the device can send, receive, or send and receive
additional paths at the address family level or the neighbor level.
During session establishment, two BGP neighbors negotiate the additional
path capabilities (whether they can send or receive) between them.
Specify whether the device can send, receive, or send and receive
additional paths at the address family level or the neighbor level.
During session establishment, two BGP neighbors negotiate the additional
path capabilities (whether they can send or receive) between them.
To send or receive
additional paths, the additional path capability must be negotiated
between the neighbors. If no negotiation occurs, even if the selection
criteria marks the best path and the neighbor is configured to advertise
the marked paths, the selections are useless because only the best path
is advertised.
Configuring BGP to
send or receive additional paths triggers negotiation of an additional
path’s capability with the device's peers. Neighbors that have
negotiated the capability are grouped together in an update group (if
other update group policies allow), and in a separate update group from
those peers that have not negotiated the capability. Therefore, the
additional path capability causes the neighbor's update group membership
to be recalculated.
Configuring BGP Additional Paths
- Configuring BGP Additional Paths for each Address Family
- Configuring BGP Additional Paths for each Neighbor
- Configuring Additional Paths Using a Peer Policy Template
- Filtering and Setting Actions for Additional Paths
DETAILED STEPS
BEFORE YOU BEGIN
Ensure that you have enabled the BGP feature (see the “Enabling the BGP Feature” section).
SUMMARY STEPS
DETAILED STEPS
BEFORE YOU BEGIN
Ensure that you have enabled the BGP feature (see the “Enabling the BGP Feature” section).
SUMMARY STEPS
DETAILED STEPS
Filtering and Setting Actions for Additional Paths
You can optionally
use a route map to filter the paths to be advertised by matching on the
prefix of additional paths that are candidates to be advertised. (These
prefixes are configured with the additional-paths selection command.)
You can also
optionally set one or more actions to take for those paths that pass
through the route map. This procedure uses the set metric command. Other set commands are available that are not shown in this task.
You would set a metric for paths marked with all
(all paths with a unique next-hop) if the neighbor is receiving the
same routes from its neighbors. Suppose the neighbor 2001:DB8::1037 is
receiving the same route from different neighbors. Routes received from
the local device have a metric of 565 and routes from another device
have a metric of 700. Routes with metric 565 have precedence over the
routes with metric 700.
Configuration Examples for BGP Additional Paths
- BGP Additional Paths Send and Receive Capabilities
- BGP Additional Paths Using a Peer Policy Template
R1
In this example,
R1's address is 2001:db8::1045; its neighbor R2 has an address of
2001:db8::1037. Updates are sent from R2 to R1 with additional-paths
(all paths advertised). Updates are sent from R1 to R2 with only the
classic BGP best path advertised because R2 can only send additional
paths, not receive additional paths.
Subscribe to:
Posts (Atom)