Now you can also download my VXLAN book from the Leanpub.com
This chapter discusses the differences between the OSPF and the IS-IS from the Network Virtualization Overlay (NVO) solution, especially from the VXLAN network perspective. First, this chapter shortly introduces some of the differences between these two protocols (terminology, timers, and LSAs). Next, this chapter explains the default behavior of the Shortest Path First (SPF) by explaining first the IS-IS reaction when Stub Network goes down. Then the same event is explained from the OSPF perspective. This chapter also introduces OSPF reaction when an Incremental SPF (iSPF) is enabled, and the interface on a link that is not belonging to the Shortest-Path Tree (SPT) goes down. The same event is also discussed with and without iSPF concerning IS-IS.
Figure 1-1: Comparison of OSPF and IS-IS.
Figure 1-1 illustrates some of the differences between the OSPF and the IS-IS Link-State Protocols. OSPF routers are identified by Router-Id (Usually a Loopback 0) while IS-IS routers are identified by NSAP address (Network Service Access Point). There is no relationship in the OSPF RID and OSPF area numbering, while first 13 bits in an NSAP address defines an IS-IS area and the next 48 bits identifies a router (usually a Loopback 0). OSPF uses Link State Updates (LSU) packets, which carries LSAs (there are several different types of LSAs), which in turns describes links connected to the router. IS-IS uses a single Link State PDU (LSP), which carries different TLVs (Type, Length, Value) fields where router describes things like its hostname (RFC5301), the IS-IS area, IP addresses of links, IPv4 prefixes that are directly connected to the router. From the router processing perspective fixed fields in OSPF LSAs do not require as much processing effort than variable length fields in IS-IS TLVs. OSPF use Database Description (DD) to give a shortcut of its Links State Data Base (LSDB) to its’ peer during adjacency negotiation (Exchange state). IS-IS use Complete Sequence Number Packet (CSNP) for the same purpose but it is refreshed every 60 by default on P2P links. OSPF LSA has fixed 60 minutes lifetime that cannot be changed and each LSA is refreshed in every 30 minutes by default. IS-IS LSP lifetime is 20 minutes by default and it can change all the way up to 18.2 hours. IS-IS LSPs are refreshed every 15 minutes by default and it launches the SPF algorithm (range 1-65535 seconds). To form an OSPF adjacency (and maintain it) between OSPF speaker the following attributes in Hello-packets must match; area-id, timers (hello and dead interval), authentication, network mask, stub-flags, options, Interface MTU and OSPF network type. In addition, the interface IP address and OSPF router-id has to be unique in the adjacent router. While OSPF has nine attributes that have to match, IS-IS only requires four matching attributes: Interface MTU, Levels, The Area-Id in Level 1 router and authentication. Also, System-Id has to be unique. Among these things, there are differences in area structure. OSPF area boundary falls on the router while in IS-IS the link is the border. The default metric in OSPF is calculated based on defined reference bandwidth/Interface bandwidth while in IS-IS the default interface metric is 10. In addition, IS-IS can signal memory overload by using “overload-bit”, OSPF does not have this option.
There are many other differences between the OSPF and the IS-IS but there are also similarities. All router inside an area, whether we are speaking about OSPF or IS-IS, has to have a common LSDB. Both protocols use the SPF algorithm to form a loop-free Shortest-Path Tree (SPT) between each router inside an area as well as adding leafs (networks) to SPT. Based on the calculation result, routers also updates their Routing Information Bases (RIB) as well as Forwarding Information Bases (FIB) if there are no better route sources like static routes available.
Figure 1-2 shows an example topology where both OSPF and IS-IS are running on each router and both protocols calculate the Shortest-Path Tree (Links participating SPT are highlighted with grey color). The topology is based on Spine-Leaf model with the difference that there is a link between the two Spine switches. The purpose of Spine-to-Spine link is to demonstrate the SPF process when the link that is not participating on a Shortest-Path Tree goes down. This kind of cabling structure might be relevant in some enterprise networks. There are six SPF scenarios in this chapter. First, this chapter explains the operation of the SPF algorithm from the IS-IS perspective when the loopback 50 interface on Leaf-101 goes down (Partial SPF). Then the same event is monitored from the OSPF perspective (Full SPF). Next, this section shows how the OSPF SPF algorithm can be optimized (Incremental SPF). Hence, this section explains how OSPF reacts when the link between Spine-11 and Spine-12 goes down when iSPF is enabled. The last section explains the same operation from the IS-IS perspective and also introduces the IS-IS SPF optimization using iSPF.
Figure 1-2: Example topology.
Scenario-1: Interface loopback 50 down on Leaf-101 (IS-IS)
Figure 1-3 illustrates the situation where the Loopback 50 interface (192.168.50.101/32) state is moved from Up to Down on Leaf-101. As a reaction to this event, Leaf-101 generates a new LSP and sends it to IS-IS neighbors. The “IP Internal Reachability Information” (Type-128) describes the network that is directly connected to the IS-IS router. The IP network 192.168.50.101 is excluded from this LSP. The packet capture is taken from the interface g0/1 on Leaf-101. LSP is flooded to Leaf-102 by both Spine switches. When Leaf-102 receives the LSP, instead of executing full SPF run by processing each LSA from its LSDB it only processes the new LSP. Leaf-102 ages out the old LSP from the LSDB and installs the information received on the newest LSP into LSDB. Also, it removes routes describing the reachability of net 192.168.50.101 from its RIB and FIB. IS-IS does not run the full SPF where the whole SPT is recalculated when the Leaf route is changed. This is why the term Partial SPF is used when speaking about the SPF run concerning IS-IS.
Figure 1-3: Interface Loopback 50 DOWN on Leaf-101 (IS-IS).
Example 1-1 shows the debug information in Leaf-101 when it receives the new LSP originated by Leaf-101.
Leaf-102#debug isis spf-events
IS-IS SPF events debugging is on for IPv4 unicast topology base
ISIS-SPF: L1 LSP 3 (1921.6800.0101.00-00) flagged for recalculation from 252321F
ISIS-SPF: LSP 3 (1921.6800.0101.00-00) Type STD
ISIS-SPF: spf_result: next_hop_parents:0x1050133C root_distance:6, parent_count:2, parent_index:4 db_on_paths:1
ISIS-SPF: Calculating routes for L1 LSP 3 (1921.6800.0101.00-00)
ISIS-SPF: lsptype:0, current_lsp(1921.6800.0101.00-00)(3) current_lsp:0xDABACA8, lsp_fragment:0xDABACA8 calling isis_walk_lsp
ISIS-SPF: Aging L1 LSP 3 (1921.6800.0101.00-00), version 15
|
Example 1-1: “Debug isis spf-events” on Leaf-102
Example 1-2 shows the LSDB concerning information received from Leaf-101. NLPID (Network Layer Protocol Identifier) describes the supported protocols (0xCC = IPv4). NLPID is shown in packet capture as “Supported Protocols” in figure 1-3. Also, hostname of the originating router is carried in TLVs. To be able to see hostname in OSPF LSDB, hostname-to-IP address mapping information has to be configured to each router.
Leaf-102#show isis database level-1 Leaf-101.00-00 detail
Tag UnderlayNet:
IS-IS Level-1 LSP Leaf-101.00-00
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
Leaf-101.00-00 0x00000010 0x4E54 1178/1198 0/0/0
Area Address: 49.0001
NLPID: 0xCC
Hostname: Leaf-101
Metric: 4 IS Spine-12.00
Metric: 2 IS Spine-11.00
IP Address: 192.168.0.101
Metric: 2 IP 10.101.11.0 255.255.255.0
Metric: 4 IP 10.101.12.0 255.255.255.0
Metric: 4 IP 10.103.101.0 255.255.255.0
Metric: 0 IP 192.168.0.101 255.255.255.255
|
Example 1-2: “show isis database level-1 Leaf-101.00-00 detail” on Leaf-102
Scenario-2: Interface loopback 50 down on Leaf-101 (OSPF)
Figure 1-4 describes the same scenario from the OSPF perspective. As soon as the interface Loopback 50 state is changed from Up to Down, Leaf-101 generates a Link State Update (LSU) packet that carries a Router-LSA including information about current usable links. Since interface Loopback 50 is down, there are only two P2P (type-1) link descriptions describing the connection to Spine switches. When Leaf-102 receives the LSU it notifies that this is the newest Router-LSA. Leaf-102 then executes the full Shortest-Path Tree calculation even though the core of the tree has not changed (example 1-3).
Figure 1-4: Interface Loopback 50 DOWN on Leaf-101 (OSPF).
The first highlighted (black and white) shows the start of the SPF algorithm. Leaf -102 re-builds the whole SPT by going through each router-LSA found on its LSDB. It moves itself as a root for the SPT. Then it finds out the closest OSPF peer which is Spine-12 and processes LSA originated by the Spine-12. This process is explained in detail in the last post “VXLAN Underlay Routing - Part I: OSPF and Dijkstra/SPF algorithm”.
Leaf-102#debug ip ospf spf intra
OSPF SPF intra debugging is on
04:50:38: OSPF-1 SPF : Detect change in LSA type 1, LSID 192.168.0.101 from 192.168.0.101 area 0
04:50:43: OSPF-1 MON : Begin SPF at 17443.145ms, process time 19052ms
04:50:43: OSPF-1 INTRA: Running SPF for area 0, SPF-type Full
04:50:43: OSPF-1 INTRA: Initializing to run spf
04:50:43: OSPF-1 INTRA: spf_intra() - rebuilding the tree
04:50:43: OSPF-1 INTRA: It is a router LSA 192.168.0.102. Link Count 2
04:50:43: OSPF-1 INTRA: Processing link 0, id 192.168.0.12, link data 10.102.12.102, type 1
04:50:43: OSPF-1 SPF : Add better path to LSA ID 192.168.0.12, gateway 10.102.12.12, dist 2
04:50:43: OSPF-1 INTRA: Putting LSA on the clist LSID 192.168.0.12, Type 1, Adv Rtr. 192.168.0.12
04:50:43: OSPF-1 SPF : Add path: next-hop 10.102.12.12, interface GigabitEthernet0/2
04:50:43: OSPF-1 INTRA: Processing link 1, id 192.168.0.11, link data 10.102.11.102, type 1
04:50:43: OSPF-1 SPF : Add better path to LSA ID 192.168.0.11, gateway 10.102.11.11, dist 4
04:50:43: OSPF-1 INTRA: Putting LSA on the clist LSID 192.168.0.11, Type 1, Adv Rtr. 192.168.0.11
04:50:43: OSPF-1 INTRA: Upheap LSA ID 192.168.0.11, Type 1, Adv 192.168.0.11 on clist from index 2 to 2
04:50:43: OSPF-1 SPF : Add path: next-hop 10.102.11.11, interface GigabitEthernet0/1
04:50:43: OSPF-1 INTRA: Downheap LSA ID 192.168.0.11, Type 1, Adv 192.168.0.11 on clist from index 1 to 1
04:50:43: OSPF-1 INTRA: It is a router LSA 192.168.0.12. Link Count 3
04:50:43: OSPF-1 INTRA: Processing link 0, id 192.168.0.11, link data 10.12.11.12, type 1
04:50:43: OSPF-1 INTRA: Ignore newdist 5 olddist 4
04:50:43: OSPF-1 INTRA: Processing link 1, id 192.168.0.102, link data 10.102.12.12, type 1
04:50:43: OSPF-1 INTRA: Ignore newdist 4 olddist 0
04:50:43: OSPF-1 INTRA: Processing link 2, id 192.168.0.101, link data 10.101.12.12, type 1
04:50:43: OSPF-1 SPF : Add better path to LSA ID 192.168.0.101, gateway 10.101.12.101, dist 6
04:50:43: OSPF-1 INTRA: Putting LSA on the clist LSID 192.168.0.101, Type 1, Adv Rtr. 192.168.0.101
04:50:43: OSPF-1 INTRA: Upheap LSA ID 192.168.0.101, Type 1, Adv 192.168.0.101 on clist from index 2 to 2
04:50:43: OSPF-1 SPF : Add path: next-hop 10.102.12.12, interface GigabitEthernet0/2
04:50:43: OSPF-1 INTRA: Downheap LSA ID 192.168.0.101, Type 1, Adv 192.168.0.101 on clist from index 1 to 1
04:50:43: OSPF-1 INTRA: It is a router LSA 192.168.0.11. Link Count 3
04:50:43: OSPF-1 INTRA: Processing link 0, id 192.168.0.12, link data 10.12.11.11, type 1
04:50:43: OSPF-1 INTRA: Ignore newdist 7 olddist 2
04:50:43: OSPF-1 INTRA: Processing link 1, id 192.168.0.102, link data 10.102.11.11, type 1
04:50:43: OSPF-1 INTRA: Ignore newdist 8 olddist 0
04:50:43: OSPF-1 INTRA: Processing link 2, id 192.168.0.101, link data 10.101.11.11, type 1
04:50:43: OSPF-1 INTRA: Add equal-length path to 192.168.0.101, dist 6
04:50:43: OSPF-1 INTRA: LSA already on the clist LSID 192.168.0.101, Type 1, Adv Rtr. 192.168.0.101
04:50:43: OSPF-1 SPF : Add path: next-hop 10.102.11.11, interface GigabitEthernet0/1
04:50:43: OSPF-1 INTRA: Downheap LSA ID 192.168.0.101, Type 1, Adv 192.168.0.101 on clist from index 1 to 1
04:50:43: OSPF-1 INTRA: It is a router LSA 192.168.0.101. Link Count 2
04:50:43: OSPF-1 INTRA: Processing link 0, id 192.168.0.12, link data 10.101.12.101, type 1
04:50:43: OSPF-1 INTRA: Ignore newdist 10 olddist 2
04:50:43: OSPF-1 INTRA: Processing link 1, id 192.168.0.11, link data 10.101.11.101, type 1
04:50:43: OSPF-1 INTRA: Ignore newdist 8 olddist 4
04:50:43: OSPF-1 INTRA: Adding Stub nets
04:50:43: OSPF-1 INTRA: Entered intra-area route sync for area 0
04:50:43: OSPF-1 INTRA: Entered intra-area route sync for area 0
04:50:43: OSPF-1 MON : End SPF at 17443.159ms, Total elapsed time 14ms
|
Example 1-3: “debug ip ospf spf intra” on Leaf-102.
Scenario-3: OSPF Incremental SPF – L55 Down on Leaf-101 (Stub)
OSPF SPT calculation can be optimized by using incremental SPF. The configuration is simple; the command ispf is added under the OSPF process. Incremental SPF is activated and SPF is run right after the command.
Example 1-4 illustrates the reaction of Leaf-102 when the interface Loopback 50 goes down on Leaf-101 and the iSPF is enabled on Leaf-102. Instead of running a full SPF, Leaf-102 runs Incremental SPF because the only change compared to the old and new LSA originated by Leaf-101 concerns the Stub Network.
Leaf-102#debug ip ospf spf intra
OSPF SPF intra debugging is on
06:13:33: OSPF-1 SPF : Detect change in LSA type 1, LSID 192.168.0.101 from 192.168.0.101 area 0
06:13:33: OSPF-1 INTRA: Insert LSA to New_LSA list type 1, LSID 192.168.0.101, from 192.168.0.101 area 0
06:13:38: OSPF-1 MON : Begin SPF at 22418.763ms, process time 23574ms
06:13:38: OSPF-1 INTRA: Running SPF for area 0, SPF-type Incremental
06:13:38: OSPF-1 INTRA: Initializing to run spf
06:13:38: OSPF-1 INTRA: Running incremental SPF for area 0
06:13:38: OSPF-1 INTRA: iSPF: Processing node 1/192.168.0.101/192.168.0.101 from the New List
06:13:38: OSPF-1 INTRA: iSPF: Checking parents
06:13:38: OSPF-1 INTRA: iSPF: trying to find a link to parent 1/192.168.0.11/192.168.0.11 in the new LSA
06:13:38: OSPF-1 INTRA: iSPF: ...found
06:13:38: OSPF-1 INTRA: iSPF: trying to find a link to parent 1/192.168.0.12/192.168.0.12 in the new LSA
06:13:38: OSPF-1 INTRA: iSPF: ...found
06:13:38: OSPF-1 INTRA: iSPF: No change in parents
06:13:38: OSPF-1 INTRA: iSPF: Scanning new LSA of node 1/192.168.0.101/192.168.0.101
06:13:38: OSPF-1 INTRA: iSPF: node 1/192.168.0.101/192.168.0.101 is NOT a parent of node 1/192.168.0.12/192.168.0.12
06:13:38: OSPF-1 INTRA: iSPF: node 1/192.168.0.12/192.168.0.12 is parent of node 1/192.168.0.101/192.168.0.101
06:13:38: OSPF-1 INTRA: iSPF: node 1/192.168.0.101/192.168.0.101 is NOT a parent of node 1/192.168.0.11/192.168.0.11
06:13:38: OSPF-1 INTRA: iSPF: node 1/192.168.0.11/192.168.0.11 is parent of node 1/192.168.0.101/192.168.0.101
06:13:38: OSPF-1 INTRA: iSPF: init all stub routes on delete list of node 1/192.168.0.101/192.168.0.101
06:13:38: OSPF-1 INTRA: iSPF: initializing node 0/192.168.50.101/192.168.0.101
06:13:38: OSPF-1 INTRA: iSPF: process all stub-routes of node 1/192.168.0.101/192.168.0.101
06:13:38: OSPF-1 INTRA: iSPF: Checking lost links of node 1/192.168.0.101/192.168.0.101
06:13:38: OSPF-1 INTRA: iSPF: Re-attaching nodes on orphans
06:13:38: OSPF-1 INTRA: spf_intra() - rebuilding the tree
06:13:38: OSPF-1 INTRA: Adding Stub nets
06:13:38: OSPF-1 INTRA: Entered intra-area route sync for area 0
06:13:38: OSPF-1 INTRA: Entered intra-area route sync for area 0
06:13:38: OSPF-1 MON : End SPF at 22418.771ms, Total elapsed time 8ms
|
Example 1-4: “debug ip ospf spf intra” on Leaf-102.
Scenario-4: OSPF Incremental SPF – Interface g0/3 Down on Spine-12 (transit link does not participate in SPT)
Incremental SPF (iSPF) also works with the transit links that are not part of the core of the SPT. When the interface g0/3 in Spine-12 goes down, Spine-12 will originate a new LSU packet where it sends fresh link descriptions. Since the link does not belong to SPT from Leaf-102 perspective, Leaf-102 does not calculate the whole tree, it just processes the router LSA received from Spine-11 and adjust the LSDB based on it.
Leaf-102#debug ip ospf spf intra
OSPF SPF intra debugging is on
06:41:37: OSPF-1 SPF : Detect change in LSA type 1, LSID 192.168.0.12 from 192.168.0.12 area 0
06:41:37: OSPF-1 INTRA: Insert LSA to New_LSA list type 1, LSID 192.168.0.12, from 192.168.0.12 area 0
06:41:42: OSPF-1 MON : Begin SPF at 24102.468ms, process time 25012ms
06:41:42: OSPF-1 INTRA: Running SPF for area 0, SPF-type Incremental
06:41:42: OSPF-1 INTRA: Initializing to run spf
06:41:42: OSPF-1 INTRA: Running incremental SPF for area 0
06:41:42: OSPF-1 INTRA: iSPF: Processing node 1/192.168.0.12/192.168.0.12 from the New List
06:41:42: OSPF-1 INTRA: iSPF: Checking parents
06:41:42: OSPF-1 INTRA: iSPF: trying to find a link to parent 1/192.168.0.102/192.168.0.102 in the new LSA
06:41:42: OSPF-1 INTRA: iSPF: ...found
06:41:42: OSPF-1 INTRA: iSPF: No change in parents
06:41:42: OSPF-1 INTRA: iSPF: Scanning new LSA of node 1/192.168.0.12/192.168.0.12
06:41:42: OSPF-1 INTRA: iSPF: node 1/192.168.0.12/192.168.0.12 is NOT a parent of node 1/192.168.0.102/192.168.0.102
06:41:42: OSPF-1 INTRA: iSPF: node 1/192.168.0.102/192.168.0.102 is parent of node 1/192.168.0.12/192.168.0.12
06:41:42: OSPF-1 INTRA: iSPF: node 1/192.168.0.102/192.168.0.102 is parent of node 1/192.168.0.12/192.168.0.12
06:41:42: OSPF-1 INTRA: iSPF: node 1/192.168.0.12/192.168.0.12 is parent of node 1/192.168.0.101/192.168.0.101
06:41:42: OSPF-1 INTRA: iSPF: init all stub routes on delete list of node 1/192.168.0.12/192.168.0.12
06:41:42: OSPF-1 INTRA: iSPF: process all stub-routes of node 1/192.168.0.12/192.168.0.12
06:41:42: OSPF-1 INTRA: iSPF: Checking lost links of node 1/192.168.0.12/192.168.0.12
06:41:42: OSPF-1 INTRA: iSPF: node 1/192.168.0.12/192.168.0.12 is NOT a parent of node 1/192.168.0.11/192.168.0.11
06:41:42: OSPF-1 INTRA: iSPF: Re-attaching nodes on orphans
06:41:42: OSPF-1 INTRA: spf_intra() - rebuilding the tree
06:41:42: OSPF-1 INTRA: Adding Stub nets
06:41:42: OSPF-1 INTRA: Entered intra-area route sync for area 0
06:41:42: OSPF-1 INTRA: Entered intra-area route sync for area 0
06:41:42: OSPF-1 MON : End SPF at 24102.474ms, Total elapsed time 6ms
|
Example 1-5: “debug ip ospf spf intra” on Leaf-102.
Scenario-5: IS-IS SPF – Interface g0/3 Down on Spine-12 (Full SPF computation)
Example 1-6 explains how ISIS reacts when interface g0/3 on Spine-12 goes down. Leaf-101 runs a full SPF and re-builds an SPT. The detailed explanation of the SPF/Dijkstra algorithm can be found from the previous post “VXLAN Underlay Routing - Part I: OSPF and Dijkstra/SPF algorithm”. When comparing debug output received from IS-IS to OSPF, the IS-IS is a bit more descriptive. The output clearly shows how the Leaf-102 installs itself from the TENT list into the PATH list. Then it moves its own IS-IS peers to TENT list. Then Leaf-102 removes the peer with the lowest metric from the TENT list and adds it into the PATH list. As a next step, Spine-12 peer Leaf-101 is moved into the TENT list (which already includes Spine-11). Then, the metric of these two are compared and the Spine-11 is moved into PATH list based on the lowest metric value. The process moves on and it is stopped when the TENT list is empty.
08:45:33: ISIS-SPF: Compute L1 SPT
08:45:33: ISIS-Stats: Compute L1 SPT
08:45:33: ISIS-SPF: Starting level-1 SPF with 1 nodes into TENT
08:45:33: ISIS-SPF: Move 1921.6800.0102.00-00 to PATHS, metric 0
08:45:33: ISIS-SPF: Remove the node from the TENT list lsp(1921.6800.0102.00-00)(1):0xF584E10
08:45:33: ISIS-SPF: Attempt to add each adj of the node to tent via add lsp routes, lsp(1921.6800.0102.00-00)(1), lsptype:0
08:45:33: ISIS-SPF: lsptype:0, current_lsp(1921.6800.0102.00-00)(1) current_lsp:0xF584E10, lsp_fragment:0xF584E10 calling isis_walk_lsp
08:45:33: ISIS-SPF: Added neighbor lsp to the tent list, link_is_p2p:1
08:45:33: ISIS-SPF: considering adj to 1921.6800.0012 (GigabitEthernet0/2) metric 2, level 1, circuit 3, adj 1
08:45:33: ISIS-SPF: (accepted)
08:45:33: ISIS-Spf: Add 1921.6800.0012.00-00 to TENT, metric 2
08:45:33: ISIS-Spf: Next hop 1921.6800.0012 (GigabitEthernet0/2)
08:45:33: ISIS-SPF: Added neighbor lsp to the tent list, link_is_p2p:1
08:45:33: ISIS-SPF: considering adj to 1921.6800.0011 (GigabitEthernet0/1) metric 4, level 1, circuit 3, adj 1
08:45:33: ISIS-SPF: (accepted)
08:45:33: ISIS-Spf: Add 1921.6800.0011.00-00 to TENT, metric 4
08:45:33: ISIS-Spf: Next hop 1921.6800.0011 (GigabitEthernet0/1)
08:45:33: ISIS-SPF: Move 1921.6800.0012.00-00 to PATHS, metric 2
08:45:33: ISIS-SPF: Remove the node from the TENT list lsp(1921.6800.0012.00-00)(2):0xFEF85C8
08:45:33: ISIS-SPF: Attempt to add each adj of the node to tent via add lsp routes, lsp(1921.6800.0012.00-00)(2), lsptype:0
08:45:33: ISIS-SPF: lsptype:0, current_lsp(1921.6800.0012.00-00)(2) current_lsp:0xFEF85C8, lsp_fragment:0xFEF85C8 calling isis_walk_lsp
08:45:33: ISIS-SPF: Failed to add neighbor lsp to the tent list, link_is_p2p:1
08:45:33: ISIS-SPF: Added neighbor lsp to the tent list, link_is_p2p:1
08:45:33: ISIS-Spf: Add 1921.6800.0101.00-00 to TENT, metric 6
08:45:33: ISIS-Spf: Next hop 1921.6800.0012 (GigabitEthernet0/2)
08:45:33: ISIS-SPF: Move 1921.6800.0011.00-00 to PATHS, metric 4
08:45:33: ISIS-SPF: Remove the node from the TENT list lsp(1921.6800.0011.00-00)(4):0xDABACA8
08:45:33: ISIS-SPF: Attempt to add each adj of the node to tent via add lsp routes, lsp(1921.6800.0011.00-00)(4), lsptype:0
08:45:33: ISIS-SPF: lsptype:0, current_lsp(1921.6800.0011.00-00)(4) current_lsp:0xDABACA8, lsp_fragment:0xDABACA8 calling isis_walk_lsp
08:45:33: ISIS-SPF: Added neighbor lsp to the tent list, link_is_p2p:1
08:45:33: ISIS-Spf: Add 1921.6800.0101.00-00 to TENT, metric 6
08:45:33: ISIS-Spf: Next hop 1921.6800.0011 (GigabitEthernet0/1)
08:45:33: ISIS-Spf: Next hop 1921.6800.0012 (GigabitEthernet0/2)
08:45:33: ISIS-SPF: Failed to add neighbor lsp to the tent list, link_is_p2p:1
08:45:33: ISIS-SPF: Failed to add neighbor lsp to the tent list, link_is_p2p:1
08:45:33: ISIS-SPF: Move 1921.6800.0101.00-00 to PATHS, metric 6
08:45:33: ISIS-SPF: Remove the node from the TENT list lsp(1921.6800.0101.00-00)(3):0xDABB208
08:45:33: ISIS-SPF: Attempt to add each adj of the node to tent via add lsp routes, lsp(1921.6800.0101.00-00)(3), lsptype:0
08:45:33: ISIS-SPF: lsptype:0, current_lsp(1921.6800.0101.00-00)(3) current_lsp:0xDABB208, lsp_fragment:0xDABB208 calling isis_walk_lsp
08:45:33: ISIS-SPF: Failed to add neighbor lsp to the tent list, link_is_p2p:1
08:45:33: ISIS-SPF: Failed to add neighbor lsp to the tent list, link_is_p2p:1
08:45:33: ISIS-SPF: Aging L1 LSP 1 (1921.6800.0102.00-00), version 41
08:45:33: ISIS-SPF: Aging L1 LSP 2 (1921.6800.0012.00-00), version 43
08:45:33: ISIS-SPF: Aging L1 LSP 3 (1921.6800.0101.00-00), version 64
08:45:33: ISIS-SPF: Aging L1 LSP 4 (1921.6800.0011.00-00), version 44
08:45:33: ISIS-Stats: SPF only compute time 0.014
08:45:33: ISIS-Stats: IPv4 RIB only compute time 0.000
08:45:33: ISIS-Stats: Complete L1 SPT,
08:45:33: ISIS-Stats: Compute time 0.014/0.014, 4/0 nodes, 4/0 links, 0 suspends
|
Example 1-6: debug isis sfp-events on Leaf-102.
Scenario-6: IS-IS Incremental SPF – Interface g0/3 Down on Spine-12 (transit link does not participate in SPT)
It is also possible to optimize the SPF algorithm in IS-IS by using Incremental SPF. Configuration is simple; add the command ispf level-1 20 under the IS-IS routing process (default value when beginning iSPF is 120 seconds). Unlike in OSPF, IS-IS configuration allows the administrator to define when the Incremental SPF is activated (when activated, SPF is done immediately).
Example 1-7 describes the SPF process in Leaf-102 when the incremental SPF is enabled and the interface g0/3 on Spine-12 state changes from up to down. Note that there is a new LSP packet received from both Spine-11 (Adding LSP: 4) and Spine-12 (Adding LSP: 2). For simplicity processing of LSA received from Spine-12 is highlighted with grey color.
08:51:41: ISIS-SPF: Compute L1 SPT
08:51:41: ISIS-Stats: Compute L1 SPT
08:51:41: ISIS-Stats:
ISIS-Stats: Starting incremental SPF for level-1
08:51:41: ISIS-SPF: I-SPF: Adding LSP: (2) to NewLSP, metric: 2
08:51:41: ISIS-SPF: I-SPF: Adding LSP: (2) to 1035B410, metric: 2. From 24FD63D
08:51:41: ISIS-SPF: I-SPF: Adding LSP: (4) to NewLSP, metric: 4
08:51:41: ISIS-SPF: I-SPF: Adding LSP: (4) to 1035B410, metric: 4. From 24FD63D
08:51:41: ISIS-SPF: I-SPF: Entering in read_lsp with node: (2)
08:51:41: ISIS-SPF: I-SPF: Delta distance to (1) is 4
08:51:41: ISIS-SPF: I-SPF: Delta distance to (3) is 0
08:51:41: ISIS-SPF: I-SPF: Searching (2) orphans
08:51:41: ISIS-SPF: L1 LSP 2 (1921.6800.0012.00-00) flagged for recalculation from 2500635
08:51:41: ISIS-SPF: I-SPF: Entering in read_lsp with node: (4)
08:51:41: ISIS-SPF: I-SPF: Delta distance to (3) is 0
08:51:41: ISIS-SPF: I-SPF: Delta distance to (1) is 8
08:51:41: ISIS-SPF: I-SPF: Delta distance to (2) is 5
08:51:41: ISIS-SPF: I-SPF: Searching (4) orphans
08:51:41: ISIS-SPF: L1 LSP 4 (1921.6800.0011.00-00) flagged for recalculation from 2500635
08:51:41: ISIS-SPF: I-SPF: Entering isis_ispf_reattach_node
08:51:41: ISIS-SPF: Aging L1 LSP 1 (1921.6800.0102.00-00), version 44
08:51:41: ISIS-SPF: Aging L1 LSP 2 (1921.6800.0012.00-00), version 46
08:51:41: ISIS-SPF: Aging L1 LSP 3 (1921.6800.0101.00-00), version 67
08:51:41: ISIS-SPF: Aging L1 LSP 4 (1921.6800.0011.00-00), version 47
08:51:41: ISIS-Stats: SPF only compute time 0.007
08:51:41: ISIS-Stats: IPv4 RIB only compute time 0.000
08:51:41: ISIS-Stats: Complete L1 SPT,
08:51:41: ISIS-Stats: Compute time 0.007/0.007, 0/0 nodes, 0/0 links, 0 suspends
|
Example 1-7: “debug isis sfp-events” on Leaf-102.
Conclusion
SPF algorithm on both OSPF and IS-IS is possible to optimize by using Incremental SPF, which means that when either Stub Network or non-SPT Transit Network goes down, routers do not have to run full SPF. Though when any link/network comes up, the full SPF is calculated by both protocols.
When discussing which Link-State Protocol is better for the Underlay Network from the VXLAN perspective, there is no clear answer. Some IS-IS properties like adjustable LSP lifetime, the new property requires only a new TLV (not totally new LSA type) and fewer attributes that have to match to form and keep an IS-IS adjacency up might make IS-IS a bit better than OSPF. The question is; are these properties relevant from VXLAN fabric Underlay Network perspective, at the end of the day there are only couple of loopback addresses (if unnumbered uplinks are used) per router that needs to be reachable throughout the infrastructure. Though it is possible that there are hundreds or even thousands of switches in VXLAN fabric. The selection still is more matter of taste than based on pure facts, both OSPF and IS-IS are suitable for Underlay Network (Authors opinion). Use the one that you know better.
RFC 8365: A Network
Virtualization Overlay Solution Using Ethernet VPN (EVPN)
RFC 1195: Use of OSI
IS-IS for Routing in TCP/IP and Dual Environments
RFC 2328: OSPF Version 2
RFC 4970: Extensions to
OSPF for Advertising Optional Router Capabilities
RFC 5301: Dynamic
Hostname Exchange Mechanism for IS-IS
RFC 5340: OSPF for IPv6
RFC 6860: Hiding
Transit-Only Networks in OSPF
Draft-bhatia-manral-isis-ospf-01: IS-IS and OSPF
Difference Discussion
Helpful artical.
ReplyDeleteThanks for a well written and informative post.
Router Login Guide for Netgear, TP-Link, D-Link and Linksys
buy the best induction cooktop in India 2021
ReplyDelete