For the longest time I had no idea what a router was despite configuring Linux for years. This is not about a hipster who is configuring his WIFI at Starbucks so he can watch the latest news while sipping on an Espresso. This is about me, a different sort of hipster, and about the '90s when Linux was all the rage, unlike these days when it's so passe that even my grandma knows how to somewhat wield it - and I did teach my grandma, I kid you not. At least how to make new folders in GNOME and so forth. But back then I had no clue what a router was even though I was configuring IP Masquareading and adding routes to the routing table. Reason being, nobody had more than one computer in a home at a time hooked up to the modem, nobody! I still remember how elite it felt when I bought my first 4-port Ethernet NIC - I thought I was God or something. Like wow man, I can make a Linux box that can serve computers in other rooms of our family home? This was a mind blowing radical idea. Today it seems so childish and many a modern "geekstresses" might mock and bully me for this moment but it is a fact. I love 4-port NICs. It's a fetish of mine I suppose. And then one day I got a job with billion dollar equipment that serves thousands of ports of Gigabits a second.
Thursday, May 10, 2018
Wednesday, February 25, 2015
OSPF for Networking Babies
So I'm on Router1 and I'd like to know what other Cisco gear is hooked up to it. That's what CDP is for.
Router1#show cdp neigh
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S -Switch, H - Host, i - IGMP, r - Repeater
Device ID Local Intrfce Holdtme Capability Platform Port ID
Router2 Fas0/0 131 R 2811 Fas 0/0
Router4 Ser0/0 131 R 2811 Ser 0/0
This output tells us there are two routers, Router2 and Router4 connected. So let's check out the connectivity to Router4 with a ping!
Router1#ping 172.16.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Great, trust me that Router2 also works. Now let's examine our routing table (RIB).
Router1#sh ip ro
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, FastEthernet0/0
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.10.0 is directly connected, Serial0/0
Just two lonely connected routes. It's not a large network, so let's hop on over to Router2 and look at it's RIB.
Router2#sh ip ro
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, FastEthernet0/0
172.16.0.0/24 is subnetted, 1 subnets
O 172.16.10.0 [110/65] via 10.1.1.1, 00:11:34, FastEthernet0/0
Here we see that one of the two routes has an O on the far left, indicating it's learned via OSPF. Whereas connected routes are added to the RIB from interfaces that are on that router, OSPF routes are dynamically learned by the OSPF routing protocol. We see that 172.16.10.0/24 is learned off of FastEthernet0/0, and in brackets we learn it's administrative distance is 110 and it's OSPF specific metric is 65. This route was learned 11 minutes ago. All straight forward stuff. But the key here is how does OSPF add routes to the RIB in the first place?
If we hop over to Router1 we see the data for OSPF process 100.
Router1#sh ip proto
Routing Protocol is "ospf 100"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 172.16.10.1
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
10.1.1.0 0.0.0.255 area 0
172.16.10.0 0.0.0.255 area 0
Routing Information Sources:
Gateway Distance Last Update
172.16.10.1 110
Distance: (default is 110)
The Router ID is the identification of Router1 in the OSPF world. This value isn't an IP address, but just looks like it as it has to be a 32-bit DDN value, even in IPv6 networks it will look like this. Without a Router ID value set, the OSPF process won't start. It's set with the router-id subcommand (for router ospf command), or IOS picks the highest IP number of a Loopback interface, or failing both it picks the highest IP number of any other IPv4 interface which is at least in an up/down state.
Below the Router ID we see "Routing for Networks". This tells us what networks are configured on this OSPF process (process 100) to be advertised into area 0. The final portion "Routing Inoformation Sources" lists the OSPF neighbors from which this router can learn routes and inject them into the RIB.
A useful command is show ip ospf int brief.
Router2#show ip ospf int brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Fa0/0 100 0 10.1.1.2/24 1 BDR 1/1
Router1#show ip ospf int brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Fa0/0 100 0 10.1.1.1/24 1 DR 1/1
Se0/0 100 0 172.16.10.1/24 64 P2P 0/0
Here we see clearly the different world view between Router1 and Router2! The State column tells us what the router thinks that particular entry is in OSPF terms. Router2 has BDR listed for the device off of Fa0/0, which is Router1. So Router2 thinks that Router1 is a BDR, while Router1 thinks that Router2 is a DR. This makes sense. DR is a Designated Router, while BDR is a Backup Designated Router. BDR takes over flooding routing updates when the DR goes down. And since we only have two routers, one of them had to be the primary. Each group of OSPF neighbors on the same data link segment go through the DR/BDR election process, as there can only be one of each per segment. This way there isn't wasting of bandwidth. All the routers on a segment send their updates to the DR, which in turn floods the updates to all the other routers, including the BDR. It's a logical star topology. The route updates are packaged inside of an LSU (Link State Update) packet, containing LSAs (Link State Advertisements). Each router receives LSAs and builds the LSDB (Link State Database). This database is what the SPF (Dijkstra) algorithm is fed with and out come the routes that the SPF adds to the RIB. So the LSDB contains LSAs, from which the SPF extrapolates the routes to add to the routing table. So the OSPF route we saw earlier means that the SPF was run and there was a corresponding LSA in the LSDB of that router! To view the LSDB use show ip ospf database.
Router2#sh ip ospf data
OSPF Router with ID (10.1.1.2) (Process ID 100)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
10.1.1.2 10.1.1.2 558 0x80000002 0x00E927 1
172.16.10.1 172.16.10.1 558 0x80000003 0x009623 2
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.1.1.1 172.16.10.1 558 0x80000001 0x0029B7
Router1#sh ip ospf data
OSPF Router with ID (172.16.10.1) (Process ID 100)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
10.1.1.2 10.1.1.2 588 0x80000002 0x00E927 1
172.16.10.1 172.16.10.1 588 0x80000003 0x009623 2
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.1.1.1 172.16.10.1 588 0x80000001 0x0029B7
As you can see both routers give us the exact same display. This makes sense since OSPF is a link state routing protocol and the LSUs ensure each router has the exact same set of LSAs in it's database, so that each router can make it's own view on the network from the same set of data.
A command that gives a similar display to show ip ospf interface brief is show ip ospf neighbors, focusing on all the neighbors that router knows.
Router2#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
172.16.10.1 1 FULL/DR 00:00:40 10.1.1.1 FastEthernet0/0
Router1#sh ip ospf neighb
Neighbor ID Pri State Dead Time Address Interface
10.1.1.2 1 FULL/BDR 00:00:40 10.1.1.2 FastEthernet0/0
As you can see in the State column the DR and BDR terms return, but now with the term FULL before them. Full is one of many states an OSPF neighbor can be in and it indicates that the LSDB has been exchanged fully and is populated, meaning it's full of LSAs! Full is the final state, and along with 2-Way, is the most common in fully working networks. Neighbor ID is just another way of saying "The Neighbor's Router ID".
Here is what the log looks like when the LSDB is "fulled" on Router2:
*Feb 25 10:22:06.334: %OSPF-5-ADJCHG: Process 100, Nbr 172.16.10.1 on FastEthernet0/0 from LOADING to FULL, Loading Done
To get to this point, we had to configure OSPF with very simple commands.
Router2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#router ospf 100
Router2(config-router)#network 10.1.1.0 0.0.0.255 area 0
Router2(config-router)#^Z
%SYS-5-CONFIG_I: Configured from console by console
The first one tells the IOS what process number to use, in this case it's process 100 with the router ospf 100 command. Next we tell the IOS what interfaces to suck in with the network command. The first parameter is the subnet ID, in this case 10.1.1.0. Then comes the wildcard mask instead of a netmask, it is 0.0.0.255. This is the same thing as a netmask of 255.255.255.0 or a /24. Wildcard masks are simply inverted netmasks, nothing complicated. Wherever there was a 255 now is a 0 and vice versa. Then we tell it what area that subnet belongs in, and in this case it's area 0, the backbone area. IOS will look for any interfaces within this subnet and start sending OSPF Hello messages to the multicast address 224.0.0.5. Any routers that have OSPF enabled on that segment will process this multicast packet and will reply appropriately. If the parameters of the Hello packets match, the OSPF routers will form adjacencies. Then they will exchange database descriptors which indicate what LSAs they know and don't know. Think of it like loading the headers of email messages before requesting the full bodies. Once the DDs have been exchanged during the ExStart state, the DR will flood the LSAs and the receiver will update it's LSDB. Then when the FULL state is reached it will run the SPF algorithm and form routes for the RIB. Each time there is a network change within an area, the SPF must be re-run to account for convergence. This is why the area separations of OSPF help trim processing time and memory consumption. If the OSPF process only has to worry about routes in one area, it doesn't care about flapping links in another area. Unless it's an ABR, an Area Border Router, these connect other areas to backbone area 0, and thus process more than one area's worth of LSAs.
A useful command for tshoots is show ip ospf interface.
Router2#sh ip ospf interface
FastEthernet0/0 is up, line protocol is up
Internet Address 10.1.1.2/24, Area 0
Process ID 100, Router ID 10.1.1.2, Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State BACKUP, Priority 1
Designated Router (ID) 172.16.10.1, Interface address 10.1.1.1
Backup Designated router (ID) 10.1.1.2, Interface address 10.1.1.2
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:00
Supports Link-local Signaling (LLS)
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 0
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 172.16.10.1 (Designated Router)
Suppress hello for 0 neighbor(s)
Note that is says on the fourth line State BACKUP. This means that Router2 is the BDR, which we already know. It gives us the Process ID (100) and Router ID (10.1.1.2) of this router, but it also tells us the Router IDs of the DR and the BDR a bit below. It gives us the full view into the timer intervals. The important bit is to note that the Dead interval is 40 seconds by default, after it times out the adjacency to that neighbor goes down.
Another usefull tshooter is show ip ospf, though this one is very long and verbose.
Router2#sh ip ospf
Routing Process "ospf 100" with ID 10.1.1.2
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
Initial SPF schedule delay 5000 msecs
Minimum hold time between two consecutive SPFs 10000 msecs
Maximum wait time between two consecutive SPFs 10000 msecs
Incremental-SPF disabled
Minimum LSA interval 5 secs
Minimum LSA arrival 1000 msecs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 0. Checksum Sum 0x000000
Number of opaque AS LSA 0. Checksum Sum 0x000000
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Number of areas transit capable is 0
External flood list length 0
Area BACKBONE(0)
Number of interfaces in this area is 1
Area has no authentication
SPF algorithm last executed 00:00:00 ago
SPF algorithm executed 3 times
Area ranges are
Number of LSA 3. Checksum Sum 0x00E927
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
A very important thing to look for is the bottom half where it says "Area BACKBONE(0)". In this section it shows how many times the SPF is executing. If you see this wildly increasing it usually means a lot of network instability.
Now you are officially an OSPF baby. :)
Router1#show cdp neigh
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S -Switch, H - Host, i - IGMP, r - Repeater
Device ID Local Intrfce Holdtme Capability Platform Port ID
Router2 Fas0/0 131 R 2811 Fas 0/0
Router4 Ser0/0 131 R 2811 Ser 0/0
This output tells us there are two routers, Router2 and Router4 connected. So let's check out the connectivity to Router4 with a ping!
Router1#ping 172.16.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Great, trust me that Router2 also works. Now let's examine our routing table (RIB).
Router1#sh ip ro
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, FastEthernet0/0
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.10.0 is directly connected, Serial0/0
Just two lonely connected routes. It's not a large network, so let's hop on over to Router2 and look at it's RIB.
Router2#sh ip ro
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, FastEthernet0/0
172.16.0.0/24 is subnetted, 1 subnets
O 172.16.10.0 [110/65] via 10.1.1.1, 00:11:34, FastEthernet0/0
Here we see that one of the two routes has an O on the far left, indicating it's learned via OSPF. Whereas connected routes are added to the RIB from interfaces that are on that router, OSPF routes are dynamically learned by the OSPF routing protocol. We see that 172.16.10.0/24 is learned off of FastEthernet0/0, and in brackets we learn it's administrative distance is 110 and it's OSPF specific metric is 65. This route was learned 11 minutes ago. All straight forward stuff. But the key here is how does OSPF add routes to the RIB in the first place?
If we hop over to Router1 we see the data for OSPF process 100.
Router1#sh ip proto
Routing Protocol is "ospf 100"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 172.16.10.1
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
10.1.1.0 0.0.0.255 area 0
172.16.10.0 0.0.0.255 area 0
Routing Information Sources:
Gateway Distance Last Update
172.16.10.1 110
Distance: (default is 110)
The Router ID is the identification of Router1 in the OSPF world. This value isn't an IP address, but just looks like it as it has to be a 32-bit DDN value, even in IPv6 networks it will look like this. Without a Router ID value set, the OSPF process won't start. It's set with the router-id subcommand (for router ospf command), or IOS picks the highest IP number of a Loopback interface, or failing both it picks the highest IP number of any other IPv4 interface which is at least in an up/down state.
Below the Router ID we see "Routing for Networks". This tells us what networks are configured on this OSPF process (process 100) to be advertised into area 0. The final portion "Routing Inoformation Sources" lists the OSPF neighbors from which this router can learn routes and inject them into the RIB.
A useful command is show ip ospf int brief.
Router2#show ip ospf int brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Fa0/0 100 0 10.1.1.2/24 1 BDR 1/1
Router1#show ip ospf int brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Fa0/0 100 0 10.1.1.1/24 1 DR 1/1
Se0/0 100 0 172.16.10.1/24 64 P2P 0/0
Here we see clearly the different world view between Router1 and Router2! The State column tells us what the router thinks that particular entry is in OSPF terms. Router2 has BDR listed for the device off of Fa0/0, which is Router1. So Router2 thinks that Router1 is a BDR, while Router1 thinks that Router2 is a DR. This makes sense. DR is a Designated Router, while BDR is a Backup Designated Router. BDR takes over flooding routing updates when the DR goes down. And since we only have two routers, one of them had to be the primary. Each group of OSPF neighbors on the same data link segment go through the DR/BDR election process, as there can only be one of each per segment. This way there isn't wasting of bandwidth. All the routers on a segment send their updates to the DR, which in turn floods the updates to all the other routers, including the BDR. It's a logical star topology. The route updates are packaged inside of an LSU (Link State Update) packet, containing LSAs (Link State Advertisements). Each router receives LSAs and builds the LSDB (Link State Database). This database is what the SPF (Dijkstra) algorithm is fed with and out come the routes that the SPF adds to the RIB. So the LSDB contains LSAs, from which the SPF extrapolates the routes to add to the routing table. So the OSPF route we saw earlier means that the SPF was run and there was a corresponding LSA in the LSDB of that router! To view the LSDB use show ip ospf database.
Router2#sh ip ospf data
OSPF Router with ID (10.1.1.2) (Process ID 100)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
10.1.1.2 10.1.1.2 558 0x80000002 0x00E927 1
172.16.10.1 172.16.10.1 558 0x80000003 0x009623 2
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.1.1.1 172.16.10.1 558 0x80000001 0x0029B7
Router1#sh ip ospf data
OSPF Router with ID (172.16.10.1) (Process ID 100)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
10.1.1.2 10.1.1.2 588 0x80000002 0x00E927 1
172.16.10.1 172.16.10.1 588 0x80000003 0x009623 2
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.1.1.1 172.16.10.1 588 0x80000001 0x0029B7
As you can see both routers give us the exact same display. This makes sense since OSPF is a link state routing protocol and the LSUs ensure each router has the exact same set of LSAs in it's database, so that each router can make it's own view on the network from the same set of data.
A command that gives a similar display to show ip ospf interface brief is show ip ospf neighbors, focusing on all the neighbors that router knows.
Router2#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
172.16.10.1 1 FULL/DR 00:00:40 10.1.1.1 FastEthernet0/0
Router1#sh ip ospf neighb
Neighbor ID Pri State Dead Time Address Interface
10.1.1.2 1 FULL/BDR 00:00:40 10.1.1.2 FastEthernet0/0
As you can see in the State column the DR and BDR terms return, but now with the term FULL before them. Full is one of many states an OSPF neighbor can be in and it indicates that the LSDB has been exchanged fully and is populated, meaning it's full of LSAs! Full is the final state, and along with 2-Way, is the most common in fully working networks. Neighbor ID is just another way of saying "The Neighbor's Router ID".
Here is what the log looks like when the LSDB is "fulled" on Router2:
*Feb 25 10:22:06.334: %OSPF-5-ADJCHG: Process 100, Nbr 172.16.10.1 on FastEthernet0/0 from LOADING to FULL, Loading Done
To get to this point, we had to configure OSPF with very simple commands.
Router2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#router ospf 100
Router2(config-router)#network 10.1.1.0 0.0.0.255 area 0
Router2(config-router)#^Z
%SYS-5-CONFIG_I: Configured from console by console
The first one tells the IOS what process number to use, in this case it's process 100 with the router ospf 100 command. Next we tell the IOS what interfaces to suck in with the network command. The first parameter is the subnet ID, in this case 10.1.1.0. Then comes the wildcard mask instead of a netmask, it is 0.0.0.255. This is the same thing as a netmask of 255.255.255.0 or a /24. Wildcard masks are simply inverted netmasks, nothing complicated. Wherever there was a 255 now is a 0 and vice versa. Then we tell it what area that subnet belongs in, and in this case it's area 0, the backbone area. IOS will look for any interfaces within this subnet and start sending OSPF Hello messages to the multicast address 224.0.0.5. Any routers that have OSPF enabled on that segment will process this multicast packet and will reply appropriately. If the parameters of the Hello packets match, the OSPF routers will form adjacencies. Then they will exchange database descriptors which indicate what LSAs they know and don't know. Think of it like loading the headers of email messages before requesting the full bodies. Once the DDs have been exchanged during the ExStart state, the DR will flood the LSAs and the receiver will update it's LSDB. Then when the FULL state is reached it will run the SPF algorithm and form routes for the RIB. Each time there is a network change within an area, the SPF must be re-run to account for convergence. This is why the area separations of OSPF help trim processing time and memory consumption. If the OSPF process only has to worry about routes in one area, it doesn't care about flapping links in another area. Unless it's an ABR, an Area Border Router, these connect other areas to backbone area 0, and thus process more than one area's worth of LSAs.
A useful command for tshoots is show ip ospf interface.
Router2#sh ip ospf interface
FastEthernet0/0 is up, line protocol is up
Internet Address 10.1.1.2/24, Area 0
Process ID 100, Router ID 10.1.1.2, Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State BACKUP, Priority 1
Designated Router (ID) 172.16.10.1, Interface address 10.1.1.1
Backup Designated router (ID) 10.1.1.2, Interface address 10.1.1.2
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:00
Supports Link-local Signaling (LLS)
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 0
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 172.16.10.1 (Designated Router)
Suppress hello for 0 neighbor(s)
Note that is says on the fourth line State BACKUP. This means that Router2 is the BDR, which we already know. It gives us the Process ID (100) and Router ID (10.1.1.2) of this router, but it also tells us the Router IDs of the DR and the BDR a bit below. It gives us the full view into the timer intervals. The important bit is to note that the Dead interval is 40 seconds by default, after it times out the adjacency to that neighbor goes down.
Another usefull tshooter is show ip ospf, though this one is very long and verbose.
Router2#sh ip ospf
Routing Process "ospf 100" with ID 10.1.1.2
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
Initial SPF schedule delay 5000 msecs
Minimum hold time between two consecutive SPFs 10000 msecs
Maximum wait time between two consecutive SPFs 10000 msecs
Incremental-SPF disabled
Minimum LSA interval 5 secs
Minimum LSA arrival 1000 msecs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 0. Checksum Sum 0x000000
Number of opaque AS LSA 0. Checksum Sum 0x000000
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Number of areas transit capable is 0
External flood list length 0
Area BACKBONE(0)
Number of interfaces in this area is 1
Area has no authentication
SPF algorithm last executed 00:00:00 ago
SPF algorithm executed 3 times
Area ranges are
Number of LSA 3. Checksum Sum 0x00E927
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
A very important thing to look for is the bottom half where it says "Area BACKBONE(0)". In this section it shows how many times the SPF is executing. If you see this wildly increasing it usually means a lot of network instability.
Now you are officially an OSPF baby. :)
Tuesday, January 13, 2015
Six Key Advantages of MPLS
MPLS has redefined the core of service provider networks by streamlining and expediting forwarding logic. Like layer 2 technologies before it, Frame Relay and ATM, it can carry any higher level technology such as IPv4, IPv6, Ethernet, HDLC and so on, via AToM, Any Tranposrt over MPLS. It shares the advantage with IP of being able to carry any payload and thus has become dominant, likewise.
An ingress PE, an MPLS ingress router on the provider's edge, attaches a label to an ingress packet and transports it over a common infrastructure to the egress PE, on it's way to it's destination IP. Since a label is used for forwarding across the core, BGP is needed only on edge routers to supply external prefixes such as customer or Internet routes. The cores need only the next-hop IP of the egress PE, which can be distributed via OSPF or IS-IS, requiring much less overhead!
As in routing, a forwarding table is used to store label mappings. The incoming label is swapped for an outgoing label at each MPLS router. This process is computationally simpler than analyzing a 4-octet IP address. Routers can push beyond 40Gbps of packets with the help of ASICs so speed isn't the main benefit of MPLS any more.
It also provides terrific support for IP over ATM integration. Prior to MPLS we had RFC 1483 define the AAL5 method, whereby each circuit had to be configured manually. There was LANE, LAN Emulation, which made the entire ATM core path between two LANs seem like a bridged Ethernet segment. As well there was MPOA, Multiprotocol Over ATM, defined by the ATM Forum, providing the tightest integration. And while they all provided a workable solution, all of them were quite cumbersome to deal with.
Prior to MPLS, a meshed customer set of sites needed a point to point link between all of the sites, requiring hundreds of links. MPLS provides optimal traffic flow, whereby the customer's edge router, CE, connects to the PE, and the MPLS core provides the meshing.
It also solves key problems for VPN users. Early VPNs used the overlay networking model, whereby a private network was created atop a common infrastructure. There was no peering with the provider's devices, each router in the customer's edge was peering with every other customer edge router. This required tedious and lengthy configuration of all sites for each new site. As well GRE tunnels can be used to provide an overlay network on layer 3 instead. The Peer to Peer model was an alternative, but it required tremendous amounts of access lists and route filtering to provide privateness required by VPNs. MPLS solves all this with the MPLS VPN application. It creates a PE-CE peering relationship, no other links are needed between sites. Customer routes are kept separate from others via the VRF (virtual routing/forwarding table) on PEs. Adding a new site requires the creation of a peering arrangement instead of reconfiguration of all the sites.
A final advantage of MPLS is traffic engineering. It allows for the utilization of under utilized links. Links that are not least-cost paths can now be used to forward traffic without the need to configure each router along the path. Only the head-end router is setup, which directs, via labels, the traffic down the entire path!
Isn't MPLS amazing? :)
An ingress PE, an MPLS ingress router on the provider's edge, attaches a label to an ingress packet and transports it over a common infrastructure to the egress PE, on it's way to it's destination IP. Since a label is used for forwarding across the core, BGP is needed only on edge routers to supply external prefixes such as customer or Internet routes. The cores need only the next-hop IP of the egress PE, which can be distributed via OSPF or IS-IS, requiring much less overhead!
As in routing, a forwarding table is used to store label mappings. The incoming label is swapped for an outgoing label at each MPLS router. This process is computationally simpler than analyzing a 4-octet IP address. Routers can push beyond 40Gbps of packets with the help of ASICs so speed isn't the main benefit of MPLS any more.
It also provides terrific support for IP over ATM integration. Prior to MPLS we had RFC 1483 define the AAL5 method, whereby each circuit had to be configured manually. There was LANE, LAN Emulation, which made the entire ATM core path between two LANs seem like a bridged Ethernet segment. As well there was MPOA, Multiprotocol Over ATM, defined by the ATM Forum, providing the tightest integration. And while they all provided a workable solution, all of them were quite cumbersome to deal with.
Prior to MPLS, a meshed customer set of sites needed a point to point link between all of the sites, requiring hundreds of links. MPLS provides optimal traffic flow, whereby the customer's edge router, CE, connects to the PE, and the MPLS core provides the meshing.
It also solves key problems for VPN users. Early VPNs used the overlay networking model, whereby a private network was created atop a common infrastructure. There was no peering with the provider's devices, each router in the customer's edge was peering with every other customer edge router. This required tedious and lengthy configuration of all sites for each new site. As well GRE tunnels can be used to provide an overlay network on layer 3 instead. The Peer to Peer model was an alternative, but it required tremendous amounts of access lists and route filtering to provide privateness required by VPNs. MPLS solves all this with the MPLS VPN application. It creates a PE-CE peering relationship, no other links are needed between sites. Customer routes are kept separate from others via the VRF (virtual routing/forwarding table) on PEs. Adding a new site requires the creation of a peering arrangement instead of reconfiguration of all the sites.
A final advantage of MPLS is traffic engineering. It allows for the utilization of under utilized links. Links that are not least-cost paths can now be used to forward traffic without the need to configure each router along the path. Only the head-end router is setup, which directs, via labels, the traffic down the entire path!
Isn't MPLS amazing? :)
Friday, December 5, 2014
STP Concepts
This introduction to STP is brought to you by the band MOPP and by their song Dream About You. They aren't financially supporting this, but sonically as it were. STP is what lets you read everything written here as well as to hear MOPP's song. It is that important! Without it, a basic LAN wouldn't work, and without LANs we cannot have InterLans, aka the Internet. After all, the Internet is just a collection of other people's networks, whether they be CANs, or larger MANs via several WAN links. Since most of our networking accomplishments are still held by men it is prudent to point out that STP was invented by a woman, Radia Perlman. So every time a gamer explores outer space, you know it's Radia to whom we owe some gratitude!
Wendell Odom wrote in his ICND2 book (200-101) that the Spanning Tree Protocol allows Ethernet LANs to utilize redundant links without the associated problems. This is a perfect summary as STP certainly does a lot of related work as well. It is clear that using redundant links in a LAN is a good way of ensuring uptime when real life happens. But we need some means of managing this redundancy, lest we fall pray to the dangers of loops. Frames, unlike packets, do not have a hop count limiting their forwarding. Once they are copied (forwarded) out of the first switch, they can be forwarded ad naseum by other switches. This results in one of three problems that STP solves - frame multiplication. Since multiple frames are now flying all over the place, we start to see an instability with the MAC address table of a switch. It hears of a destination on one port, then on the other port, so it updates it's MAC table over and over and that results in instability, making forwarding plane's task impossible. All of that results in the third problem that STP solves - broadcast storms (see broadcast radiation). Even one frame looping can cause a storm. And these storms can even bring down PCs, not just switches. When the NIC has to process copious volumes of broadcasts, it takes a toll on the CPU, whether in the switch or an end-user PC. Broadcast storms are as dangerous as their real world counterparts and thus must be prevented.
A good way to determine what VLAN an interface is on is to use show interfaces status. It's left-most column shows the port, while the middle column shows the associated VLAN. It also indicates which ports are trunks and thus carry traffic for all VLANs. An alternative way, with a differently organized display, is the command: show vlan brief. On the left it lists the VLAN names, and on the right, what ports belong to it. So it depends if you want the output ordered by ports or by VLANs. The latter even shows names whereas the former only shows numbers. Alternatively if you only care about trunks issue show interfaces trunk. It's output is kinda verbose (with long English sentences). It shows what VLANs are active on what trunk, in case someone's configured it specifically for load sharing.
STP is also known by the anti-human robot term: 802.1D (just see how many of such terms you can memorize)! It's updated version, RSTP, is known also by a robotic term: 802.1w. Some high up priests believe naming things with seemingly random numbers and letters is wiser than using labels such as STP5 or similar. STP concerns itself with two very specific and well defined goals. First, to not cut off any part of the LAN from any other part by blocking too many ports. Second, for frames to have a short life and not to loop. To accomplish it's goal STP adds an additional check to a port - whether it can forward frames or not. If it's in an STP forwarding state, it works as usual. If it's in the blocking state, it doesn't forward user frames, only BPDUs, used by the switches to exchange hellos and learn the cost of links (distances) between them. BPDU (Bridge PDU) is also used for the election of a root bridge by the Spanning Tree Algorithm (STA).
On all non-root switches, the port closest (by cost) to the root switch is called the root port (RP) and is placed into a forwarding state. Usually in enterprise networks (or other multi-switch environments), two switches end up connected to the same segment. The switch with the lowest root cost (closest to the root switch by cost) is called the designated switch, and it's port on that particular segment is called the designated port (DP). It is placed into a forwarding state. All other ports are placed into a blocking state. That's right! No traffic will flow down anything in the blocking state, except for BPDUs of course. This is important so that during topology changes these blocked ports can move to the forwarding state to take over for a failed link, a failed switch, or other configuration change.
Another value held in the BPDU is the BID (bridge ID). It is 8-bytes consisting of a 2-byte priority field (which should really be called the distance) and 6-byte MAC address of the switch. BIDs govern how root switches are elected. The switch with the lowest BID wins (opposite of how auctions work!). The reason I say that the priority (first 2-byte value) should be called distance is because the lower the value the better for the victory of the election process. Usually a priority 2 issue is more important than a priority 1 issue, but the designers have created yet another counter-intuitive system and so the lower the priority the better. Should two switches have the same priority, then the lowest MAC address wins. This is also counter-intuitive. As older gear on a network is likely to have a lower MAC address. This means when you add a brand new more powerful switch, it likely won't win the election! How sad of a design choice is that? But fear not, the priority of the BID can be adjusted. It's default value is 32,768, and must be set in increments of 4096 (another silly design decision!) to a maximum of 61,440. Two other important values of note are 24,576 and 28,762 that are set automagically by IOS (configuring STP on Catalyst).
Now let STP do it's work and go check out MOPP's Dream About You!
Wendell Odom wrote in his ICND2 book (200-101) that the Spanning Tree Protocol allows Ethernet LANs to utilize redundant links without the associated problems. This is a perfect summary as STP certainly does a lot of related work as well. It is clear that using redundant links in a LAN is a good way of ensuring uptime when real life happens. But we need some means of managing this redundancy, lest we fall pray to the dangers of loops. Frames, unlike packets, do not have a hop count limiting their forwarding. Once they are copied (forwarded) out of the first switch, they can be forwarded ad naseum by other switches. This results in one of three problems that STP solves - frame multiplication. Since multiple frames are now flying all over the place, we start to see an instability with the MAC address table of a switch. It hears of a destination on one port, then on the other port, so it updates it's MAC table over and over and that results in instability, making forwarding plane's task impossible. All of that results in the third problem that STP solves - broadcast storms (see broadcast radiation). Even one frame looping can cause a storm. And these storms can even bring down PCs, not just switches. When the NIC has to process copious volumes of broadcasts, it takes a toll on the CPU, whether in the switch or an end-user PC. Broadcast storms are as dangerous as their real world counterparts and thus must be prevented.
Determining VLANs and MAC Tables
Ethernet LANs may vary in size but always consist of three parts: NICs, cables, and switches. When a frame arrives on a port of a switch, before it can be forwarded the switch must first ascertain what VLAN (virtual LAN) it belongs to. If it came on an access port (not from another switch) then the port's config indicates which VLAN it belongs to. If it came off a trunk (connected to another switch) the VLAN info is in the tag added to the frame. If there is no tag, it's the native VLAN (by default VLAN 1). After the VLAN is determined, the source MAC address is added to the MAC address table (CAM). As well the interface on which it came from and the VLAN is also associated with the entry. As far as layer 2 is concerned, we now know what is located off of that port! Next the switch compares the frame's destination MAC address with the other entries in the MAC address table. If it finds a match, it forwards it to the matched port (interface). Otherwise it floods the frame out all ports associated for the VLAN to which the frame belongs to. This includes trunk ports, too. That's all there is to the switching logic. As it's executed sometimes thousands of times a second, it's gotta be fast and simple! On Cisco switches to view the MAC address table use: show mac address-table dynamic. The output of that command doesn't list anything specific to STP. However, as STP affects what MAC addresses are learned from what ports (as it can block frames on certain ports), it may happen that you don't see entries for certain ports at all on this list. Lack of entries on the list may mean non-STP related causes.A good way to determine what VLAN an interface is on is to use show interfaces status. It's left-most column shows the port, while the middle column shows the associated VLAN. It also indicates which ports are trunks and thus carry traffic for all VLANs. An alternative way, with a differently organized display, is the command: show vlan brief. On the left it lists the VLAN names, and on the right, what ports belong to it. So it depends if you want the output ordered by ports or by VLANs. The latter even shows names whereas the former only shows numbers. Alternatively if you only care about trunks issue show interfaces trunk. It's output is kinda verbose (with long English sentences). It shows what VLANs are active on what trunk, in case someone's configured it specifically for load sharing.
STP is also known by the anti-human robot term: 802.1D (just see how many of such terms you can memorize)! It's updated version, RSTP, is known also by a robotic term: 802.1w. Some high up priests believe naming things with seemingly random numbers and letters is wiser than using labels such as STP5 or similar. STP concerns itself with two very specific and well defined goals. First, to not cut off any part of the LAN from any other part by blocking too many ports. Second, for frames to have a short life and not to loop. To accomplish it's goal STP adds an additional check to a port - whether it can forward frames or not. If it's in an STP forwarding state, it works as usual. If it's in the blocking state, it doesn't forward user frames, only BPDUs, used by the switches to exchange hellos and learn the cost of links (distances) between them. BPDU (Bridge PDU) is also used for the election of a root bridge by the Spanning Tree Algorithm (STA).
STA
The STA ensures there is only one path through the tree of Ethernet LAN switches and blocks all other redundant ports. This means you don't get to use them for added bandwidth since the redundant links will be idleing. The only way to solve this problem is to use EtherChannel. STA does it's job by first electing a root bridge, or in today's lingo, a root switch. Apparently most of the info on STP still refers to bridges so beware of that as there aren't many bridges in the modern ecosystem. When the STA elects a root bridge, all of its ports are placed into the forwarding state - no blocking happens at the root! Imagine it as the base of a tree. The water goes up from the root to all the other branches to reach the leaves. All paths from the root must be open or some part of the tree will be cut off from the water supply. Much the same way, all paths from the root switch must be open to connected switches.On all non-root switches, the port closest (by cost) to the root switch is called the root port (RP) and is placed into a forwarding state. Usually in enterprise networks (or other multi-switch environments), two switches end up connected to the same segment. The switch with the lowest root cost (closest to the root switch by cost) is called the designated switch, and it's port on that particular segment is called the designated port (DP). It is placed into a forwarding state. All other ports are placed into a blocking state. That's right! No traffic will flow down anything in the blocking state, except for BPDUs of course. This is important so that during topology changes these blocked ports can move to the forwarding state to take over for a failed link, a failed switch, or other configuration change.
BPDUs and BIDs
BPDUs are generated only by the root switch but are updated by all other switches. The cost field is set to 0 at the root, and is incremented on arrival by each switch subsequently. Cost values are 100 for 10Mbit, 19 for 100mbit, 4 for 1GBit, and 2 for 10Gbit. These numbers decrease for higher speeds, which is very counter-intuitive since speeds are likely to rise tremendously in the future. It is useful to memorize these specific numbers, as they come in handy for tshoots! So if there are 3 switches with two links of 1Gbit each between them, the root cost from the third switch is 8 (4+4). STA doesn't care about the number of hops, it cares only about the speed of the links. A path that takes 3 switches may have a lower cost than a path going through 2.Another value held in the BPDU is the BID (bridge ID). It is 8-bytes consisting of a 2-byte priority field (which should really be called the distance) and 6-byte MAC address of the switch. BIDs govern how root switches are elected. The switch with the lowest BID wins (opposite of how auctions work!). The reason I say that the priority (first 2-byte value) should be called distance is because the lower the value the better for the victory of the election process. Usually a priority 2 issue is more important than a priority 1 issue, but the designers have created yet another counter-intuitive system and so the lower the priority the better. Should two switches have the same priority, then the lowest MAC address wins. This is also counter-intuitive. As older gear on a network is likely to have a lower MAC address. This means when you add a brand new more powerful switch, it likely won't win the election! How sad of a design choice is that? But fear not, the priority of the BID can be adjusted. It's default value is 32,768, and must be set in increments of 4096 (another silly design decision!) to a maximum of 61,440. Two other important values of note are 24,576 and 28,762 that are set automagically by IOS (configuring STP on Catalyst).
Root Election Process
The election process in general is quite simple. At the onset, all switches believe they are root. So they all send BPDUs claiming so (egotistical, eh?). Then when they hear of another switch with a better BID, they stop advertising their inferior selves (a technical term) and start advertising the superior BPDU. The BPDU carries the originator's MAC address, so the switches know who is the root. After convergence, all the switches agree on one switch to be the root as they all follow the same STA so they are governed by the same rules. No chance for opposition at all! :)Link Costs
Remember those link costs I said were silly but you had to memorize? Well they are also configurable. So you could, technically, tell a switch which path is redundant, which to prefer and so forth. Just be sure you configure the same cost on both ends of the link, as these settings aren't synchronized. Things would get totally weird if on one end you had a cost of 4 and on the other end you had a cost of 19. I'm too lazy to do the math to figure out what would result, but I bet it wouldn't be ideal.Delays
During a topology change, such as due to a failed link, there is a danger of a loop causing one of those lovely storms I mentioned earlier. There is a solution to that and it comes in the form of delays. Three to be exact. The Hello timer is set by default to 2 seconds and is the duration which the switch waits before sending the next BPDU Hello packet. So every two seconds, the root switch sends a BPDU and the other switches propagate it, updating it in the process. Should a Hello packet not arrive, there is a MaxAge timer, by default set to 10 times the length of the Hello timer. Thus, if within 20 seconds a switch doesn't receive a Hello, it will run the STA again and change which ports are in blocking or in forwarding. However, going back from Blocking to Forwarding, isn't immediate. There are two temporary states: Listening and Learning. Each uses the Forwarding timer of 15 seconds and neither forwards any frames other than BPDUs. In the Listening stage the switch is waiting for MACs to arrive and it clears house of stale entries in the MAC address table (CAM). In Learning, it is adding MACs to the address table, and still not forwarding frames at all. All this means is that for a port to go to a Forwarding state it can take up to 50 seconds (20+15+15). Pretty slow eh? That's why Rapid STP was invented, it solves that problem.EtherChannel, PortFast, and BPDU Guard
I mentioned EtherChannel earlier. It essentially treats multiple links as one interface, and thus STP doesn't react when one of it's links changes state, only when the bundle as a whole changes state, or rather when the last link in the group fails. On access ports, there is often no need to go through the laborious process of Listening and Learning states so there is a PortFast option for those ports, which eliminates the 30 second delay entirely. This is of great benefit to DHCP clients such as workstations. Another feature is called BPDU Guard. It disables a port if BPDU packets arrive on it. This is useful within corporate environments where it's undesirable to allow a random switch at someone's desk to join the network. The danger is that this little consumer switch may become the root switch and cause the whole network a lot of problems. Again, BPDU Guard is only to be used on access ports.Now let STP do it's work and go check out MOPP's Dream About You!
Saturday, November 1, 2014
Cisco Routers and Missing Passwords
There is no way to get a lost password from a router, if it is a secret. If, however, you have physical access to the router, you can boot it so that it bypasses it's config, passwords and all, and then you can change the passwords, all of them, to whatever you please.
This procedure requires knowing a bit about the config register. Its value tells the router what to do upon next reset (reboot).
The break sequence usually is Ctrl-Break. But that doesn't work in all cases and Cisco has a nice list compiled. One way to simulate the break sequence is to connect at 1200 baud, 8N1, and then hold space for 15 seconds, after which you reconnect at 9600 baud, 8N1 again, and then you can do your thing.
Once in ROMMON change the register first with confreg 0x2142 and then issue reset to reload the device. It will boot into IOS and won't load the startup-config and thus will prompt you with the setup process. You can skip it with CTRL-C. Then you are free to look at the startup-config, or even copy it to the running-config. If you do this, simply change the passwords, issue no shutdown on all your interfaces, and reload. Make sure you record the passwords in a secure document or app as going through this process isn't very convenient and cannot be done remotely!
I wish this whole process of entering ROMMON wasn't so kludgy and so backwards. I wish we could just press the letter "q" during the boot process and enter ROMMON, instead of relying on some special and secretive break sequence. But that is not how the engineering minds designed these systems and so we must learn their ways if we don't have the password.
This procedure requires knowing a bit about the config register. Its value tells the router what to do upon next reset (reboot).
- 0x2100: Boot into ROMMON before IOS
- 0x2101: Boot the IOS from Flash
- 0x2102: Boot the IOS as specified by the boot system commands in the startup-config
- 0x2142: Bypass the startup-config (and enter setup mode)
The break sequence usually is Ctrl-Break. But that doesn't work in all cases and Cisco has a nice list compiled. One way to simulate the break sequence is to connect at 1200 baud, 8N1, and then hold space for 15 seconds, after which you reconnect at 9600 baud, 8N1 again, and then you can do your thing.
Once in ROMMON change the register first with confreg 0x2142 and then issue reset to reload the device. It will boot into IOS and won't load the startup-config and thus will prompt you with the setup process. You can skip it with CTRL-C. Then you are free to look at the startup-config, or even copy it to the running-config. If you do this, simply change the passwords, issue no shutdown on all your interfaces, and reload. Make sure you record the passwords in a secure document or app as going through this process isn't very convenient and cannot be done remotely!
I wish this whole process of entering ROMMON wasn't so kludgy and so backwards. I wish we could just press the letter "q" during the boot process and enter ROMMON, instead of relying on some special and secretive break sequence. But that is not how the engineering minds designed these systems and so we must learn their ways if we don't have the password.
Wednesday, October 22, 2014
Setting up OSPFv3 on a broadcast network
Setting up OSPFv3 (IPv6) doesn't require much effort if you already know EIGRPv6, which I covered in my last post. There are differences, obviously, such as OSPF using an independent process number instead of a network-wide AS number like EIGRP. As well, OSPF pools updates into a hub type of configuration known as a DR and BDR on broadcast type networks, such as Ethernet, whereas EIGRP requires that all neighbors talk to all other neighbors, thus being a tad more wasteful. But aside from these major differences, the configurations are similar, also applied on a sub interface level. We simply tell the IOS which interfaces are to be active in the OSPF conversation and any networks assigned to them end up being exchanged.
We are using a similar setup as with EIGRP, except now there are four routers connected via Metro Ethernet (it looks like a LAN switch to IOS) - Bloor, Booth, Kensington and the new Spadina office. In the EIGRPv6 tutorial, I configured IPv6 addresses on the WAN side as I'm used to doing that in the IPv4 world, but there is no need for that anymore, since the interfaces use LLA (link-local addresses) for routing protocols on the same data link. If the WAN interfaces are going to be reachable via IPv6 for other purposes they should obviously have an address other than an LLA, as LLAs are not routable, unlike GUAs (global unicast addresses).
Engineering (Bloor)
2001:4:4:4::/64
2001:5:5:5::/64
2001:6:6:6::/64
2001:7:7:7::/64
FD00:8:8:8::/64
Sales (Kensington)
2001:1:1:1::/64
Support (Booth)
2001:2:2:2::/64
2001:3:3:3::/64
Datacentre (Spadina)
2001:9:9:9::/64
spadina#show ipv6 interface FE0/1
FastEthernet0/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::20C:26FF:FE50:8795
Global unicast address(es):
2001:9:9:9::1, subnet is 2001:9:9:9::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF00:1
FF02::1:FF50:8795
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
Hosts use stateless autoconfig for addresses.
Third line is the header "Global unicast address(es:", below which we see that the :9 address is assigned properly. Below it IOS has automatically joined this interface to several address groups. Notably FF02:1 for all IPv6 devices, and FF02:2 for all IPv6 routers (as opposed to hosts).
Let's look at a similar config on Bloor, which has many more networks:
bloor#show ipv6 interface FE0/1
FastEthernet0/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::20C:21FF:FE10:5542
Global unicast address(es):
2001:4:4:4::1, subnet is 2001:4:4:4::/64
2001:5:5:5::1, subnet is 2001:5:5:5::/64
2001:6:6:6::1, subnet is 2001:6:6:6::/64
2001:7:7:7::1, subnet is 2001:7:7:7::/64
FD00:8:8:8::1, subnet is FD00:8:8:8::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF00:1
FF02::1:FF10:5542
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
Hosts use stateless autoconfig for addresses.
Very similar output, except there are simply more entries below the third line header. We see that this router is connected to 4 subnets in 2001 block and one subnet in the unique local FD00 range. Technically these are called prefixes, but Cisco still retains the term subnet in the IOS.
Now let's configure OSPFv3 on Spadina:
spadina#conf t
Enter configuration commands, one per line. End with CNTL/Z.
spadina(config)#ipv6 router ospf 137
% IPv6 routing not enabled.
We get an error if we try it out of the blue. IOS will not let us configure any IPv6 protocols unless IPv6 unicast routing is enabled beforehand. The IPv6 routing process won't run without the ipv6 unicast-routing global command and without this process none of the routing processes for IPv6 have anything to latch onto.
spadina(config)#ipv6 unicast-routing
spadina(config)#ipv6 router ospf 137
*Oct 22 14:55:07.539: %OSPF-4-NORTRID: OSPF process 137 cannot pick a router-id.
Please configure manually or bring up an interface with an ip address.
We have successfully enabled IPv6 unicast routing, but failed to start the OSPFv3 process. The router ID, just like with EIGRP, must be configured manually via the router-id router sub command if no IPv4 interfaces are up/up. This is because the RID is still a 32-bit value, and cannot arbitrarily pick it's own value, nor is there currently any mechanism for deriving one from the IPv6 128-bit value. We can easily add a RID after this error message or by entering router ospf 137 first from the configure mode.
spadina(config-rtr)#router-id 1.1.1.1
That wasn't so hard! Please note that the 137 after ospf is the process ID, and is usually an arbitrary number chosen by you, the network administrator. It doesn't have to be 137, most people usually settle on 1 with the command router ospf 1. These numbers also don't have to match from one router to the next, as you'll see in our Bloor config, we use a different number. It simply identifies the process number within the IOS hierarchy, and has no bearing on routing nor on packet flow. In EIGRP, the number in the router eigrp 701 was the autonomous system number and it had to match across the whole EIGRP network. With OSPF, it doesn't have to match.
Next we add our interface to the OSPFv3 process. OSPF will automatically pick up any configured prefixes (subnets) from the interface config and start sending an LSA (LSU!) to the DRs and BDRs, which are two elected routers. Let's configure the interface:
spadina#conf t
Enter configuration commands, one per line. End with CNTL/Z.
spadina(config)#int FE0/1
spadina(config-if)#ipv6 ospf 137 ?
area Set the OSPF area ID
spadina(config-if)#ipv6 ospf 137 area 0
That's all it takes to add an interface with all its subnets to OSPF for exchange. To verify we can use the show ipv6 protocols command:
spadina#show ipv6 protocols
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPV6 Routing Protocol is "ospf 137"
Interfaces (Area 0):
FastEthernet0/1
Redistribution:
None
As you can tell the interface has been added to Area 0. OSPF is a bit more efficient than EIGRP. Whereas in EIGRP we had to configure an autonomous system (AS) number for the whole network, with OSPF we configure areas to break up the network into smaller chunks. Area 0 was configured with the "area 0" keyword. It is known as the backbone area, and all other areas must be connected to it. Only a router may connect one area to another. This means that a router that connects any area to the backbone will have to be a part of both areas, and thus will require two commands for that interface with different area numbers, obviously. This type of router is called an ABR (area border router). We will not be configuring any of those, as that's a bit more advanced. Just remember that in order to speed up routing updates, the routing tables get broken up into areas, that way only routes within each area get updated and nothing from the outside. Now let's configure Bloor:
bloor(config)#ipv6 unicast-routing
bloor(config)#ipv6 router ospf 37
*Oct 22 15:08:11.518: %OSPF-4-NORTRID: OSPF process 37 cannot pick a router-id.
Please configure manually or bring up an interface with an ip address.
bloor(config-rtr)#router-id 2.2.2.2
bloor(config-rtr)#exit
bloor(config)#int FE0/1
bloor(config-if)#ipv6 ospf 37 area 0
bloor(config-if)#end
bloor#show ipv6 protocols
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPV6 Routing Protocol is "ospf 37"
Interfaces (Area 0):
FastEthernet0/1
Redistribution:
None
We've done all the same things as on Spadina. The only difference is that here we've chosen a different process ID, 37. We're being funny with these numbers just to illustrate they don't need to match, it would have made more sense in a production environment to pick something easier to troubleshoot like 1 obviously.
We've gone ahead and configured the other two routers. If we look at the output of show ipv6 ospf on the Booth router we get a lot of, mostly, useless statistics:
booth#show ipv6 ospf
Routing Process "ospf 1" with ID 4.4.4.4
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
Initial SPF schedule delay 5000 msecs
Minimum hold time between two consecutive SPFs 10000 msecs
Maximum wait time between two consecutive SPFs 10000 msecs
Incremental-SPF disabled
Minimum LSA interval 5 secs
Minimum LSA arrival 1000 msecs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 0. Checksum Sum 0x000000
Number of opaque AS LSA 0. Checksum Sum 0x000000
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Number of areas transit capable is 0
External flood list length 0
Area BACKBONE(0)
Number of interfaces in this area is 1
Area has no authentication
SPF algorithm last executed 00:00:00 ago
SPF algorithm executed 1 times
Area ranges are
Number of LSA 1. Checksum Sum 0x00A797
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
The important bit here is the first line which tells us the OSPF process number, in this case 1, and the router ID is 4.4.4.4, though the word "router" is omitted from router ID and it just says ID. The IOS is funky like that sometimes. But we still won't have any DRs, BDRs, nor routes being exchanged. This is because all of these interface configs were done on our LAN interfaces. We also need to enable OSPF on the WAN interfaces so that the LAN subnets can be exchanged. This is easily done and is nearly identical. Here is an example from Spadina:
spadina(config)#int FE0/0
spadina(config-if)#ipv6 ospf 137 area 0
OSPFv3: No IPv6 enabled on this interface.
Uh-Oh! What does this mean? I thought interfaces didn't need specific IPv6 addresses assigned to them since ULA (unique local addresses) took care of that on data-links for us. Why doesn't this interface have an FE80 address already assigned to it? Clearly without an IPv6 address, we can't enable OSPFv3 on an interface. That would be like asking for mail to be delivered to a house that hasn't been issued a street number yet.
FE80 addresses (ULAs) are only assigned by IOS when the first ipv6 address command is issued. Until then, the interface remains unassigned in the IPv6 realm and no routing protocols may be enabled. So we go ahead and assign an IPv6 address for the magic to begin:
spadina(config-if)#ipv6 address FD00:1:1:1::4/64
spadina(config-if)#ipv6 ospf 137 area 0
The rest of the routers are numbered just like in the EIGRPv6 Triangle tutorial:
Bloor
FD00:1:1:1::1
Kensington
FD00:1:1:1::2
Booth
FD00:1:1:1::3
Spadina
FD00:1:1:1::4
That's all it takes. After a short delay we get this on our consoles:
*Oct 22 15:47:04.799: %OSPF-5-ADJCHG: Process 137, Nbr 3.3.3.3 on FastEthernet0/0 from LOADING to FULL, Loading Done
*Oct 22 15:47:04.193: %OSPF-5-ADJCHG: Process 137, Nbr 4.4.4.4 on FastEthernet0/0 from LOADING to FULL, Loading Done
These two lines tell us that we have formed an adjacency with two neighbors. The Nbr part is short for Router-ID, and it tells us that routers 3.3.3.3 and 4.4.4.4 have gone from a LOADING phase, whereby the LSA are being exchanged, to a FULL state, whereby all the LSA are finished transferring. We can check our OSPFv3 neighbors to be sure:
spadina#show ipv6 ospf neighbo
Neighbor ID Pri State Dead Time Interface ID Interface
3.3.3.3 1 FULL/DR 00:00:40 3 FastEthernet0/0
2.2.2.2 1 2WAY/DROTHER 00:00:40 3 FastEthernet0/0
4.4.4.4 1 FULL/BDR 00:00:40 3 FastEthernet0/0
As you can see, we have three neighbors, but we only have full adjacencies with two of them. The router with RID 2.2.2.2 is not in a FULL state, but in a 2WAY state, which comes before FULL. This means we are not exchanging LSAs with it. The router 3.3.3.3 is the DR (as noted after the word FULL), which means it's the designated router. It's backup is the BDR, which is 4.4.4.4. In case the DR goes down, the BDR takes over. No matter how many OSPFv3 routers are on this network, there will ever only be two adjacencies, one with the DR and one with the BDR. All other routers will be in a 2WAY/DROTHER state if they are fully configured. They will still have the same routing table, but will have received it from the DR and not from each of the other routers. Basically the DR (and BDR) act as a kind of a hub in a hub and spoke network. The routers send their LSAs to the two of them, and they are in turn responsible for updating the rest of the network. This is counter to the way EIGRP works, where each router forms a neighbor relationship with every other router, which is kinda wasteful.
We can now look at the routing table:
spadina#show ipv6 route
IPv6 Routing Table
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
D - EIGRP, EX - EIGRP external
C FD00:1:1:1::/64 [0/0]
via FastEthernet0/0, directly connected
L FD00:1:1:1::4/128 [0/0]
via FastEthernet0/0, receive
C 2001:9:9:9::/64 [0/0]
via FastEthernet0/1, directly connected
L 2001:9:9:9::1/128 [0/0]
via FastEthernet0/1, receive
O 2001:1:1:1::/64 [110/2]
via FE80::20C:39FF:FE62:6232, FastEthernet0/0
O 2001:2:2:2::/64 [110/2]
via FE80::20C:31FF:FE68:8461, FastEthernet0/0
O 2001:4:4:4::/64 [110/2]
via FE80::20C:84FF:FE99:1947, FastEthernet0/0
L FF00::/8 [0/0]
via Null0, receive
All the routes that start with O on the far left are from the OSPF process. We see all the routes have made it, despite the various routers having differing process IDs. However, we see that only the 2001:4:4:4::/64 network has made it from Bloor. What happened to the rest? Well kind of like with EIGRP, we did not configure redistribute connected command, which would have inserted all the connected routes into OSPF. Without this command, IOS only can add an LSA for the first network of an interface. The rest just get ignored by the OSPF process.
Enjoy!
We are using a similar setup as with EIGRP, except now there are four routers connected via Metro Ethernet (it looks like a LAN switch to IOS) - Bloor, Booth, Kensington and the new Spadina office. In the EIGRPv6 tutorial, I configured IPv6 addresses on the WAN side as I'm used to doing that in the IPv4 world, but there is no need for that anymore, since the interfaces use LLA (link-local addresses) for routing protocols on the same data link. If the WAN interfaces are going to be reachable via IPv6 for other purposes they should obviously have an address other than an LLA, as LLAs are not routable, unlike GUAs (global unicast addresses).
Addressing
We're using the same addressing scheme as for EIGRP, with the addition of the Spadina router.Engineering (Bloor)
2001:4:4:4::/64
2001:5:5:5::/64
2001:6:6:6::/64
2001:7:7:7::/64
FD00:8:8:8::/64
Sales (Kensington)
2001:1:1:1::/64
Support (Booth)
2001:2:2:2::/64
2001:3:3:3::/64
Datacentre (Spadina)
2001:9:9:9::/64
Config
Before enabling OSPFv3, let's take a look at what an interface on Spadina looks like.spadina#show ipv6 interface FE0/1
FastEthernet0/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::20C:26FF:FE50:8795
Global unicast address(es):
2001:9:9:9::1, subnet is 2001:9:9:9::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF00:1
FF02::1:FF50:8795
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
Hosts use stateless autoconfig for addresses.
Third line is the header "Global unicast address(es:", below which we see that the :9 address is assigned properly. Below it IOS has automatically joined this interface to several address groups. Notably FF02:1 for all IPv6 devices, and FF02:2 for all IPv6 routers (as opposed to hosts).
Let's look at a similar config on Bloor, which has many more networks:
bloor#show ipv6 interface FE0/1
FastEthernet0/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::20C:21FF:FE10:5542
Global unicast address(es):
2001:4:4:4::1, subnet is 2001:4:4:4::/64
2001:5:5:5::1, subnet is 2001:5:5:5::/64
2001:6:6:6::1, subnet is 2001:6:6:6::/64
2001:7:7:7::1, subnet is 2001:7:7:7::/64
FD00:8:8:8::1, subnet is FD00:8:8:8::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF00:1
FF02::1:FF10:5542
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
Hosts use stateless autoconfig for addresses.
Very similar output, except there are simply more entries below the third line header. We see that this router is connected to 4 subnets in 2001 block and one subnet in the unique local FD00 range. Technically these are called prefixes, but Cisco still retains the term subnet in the IOS.
Now let's configure OSPFv3 on Spadina:
spadina#conf t
Enter configuration commands, one per line. End with CNTL/Z.
spadina(config)#ipv6 router ospf 137
% IPv6 routing not enabled.
We get an error if we try it out of the blue. IOS will not let us configure any IPv6 protocols unless IPv6 unicast routing is enabled beforehand. The IPv6 routing process won't run without the ipv6 unicast-routing global command and without this process none of the routing processes for IPv6 have anything to latch onto.
spadina(config)#ipv6 unicast-routing
spadina(config)#ipv6 router ospf 137
*Oct 22 14:55:07.539: %OSPF-4-NORTRID: OSPF process 137 cannot pick a router-id.
Please configure manually or bring up an interface with an ip address.
We have successfully enabled IPv6 unicast routing, but failed to start the OSPFv3 process. The router ID, just like with EIGRP, must be configured manually via the router-id router sub command if no IPv4 interfaces are up/up. This is because the RID is still a 32-bit value, and cannot arbitrarily pick it's own value, nor is there currently any mechanism for deriving one from the IPv6 128-bit value. We can easily add a RID after this error message or by entering router ospf 137 first from the configure mode.
spadina(config-rtr)#router-id 1.1.1.1
That wasn't so hard! Please note that the 137 after ospf is the process ID, and is usually an arbitrary number chosen by you, the network administrator. It doesn't have to be 137, most people usually settle on 1 with the command router ospf 1. These numbers also don't have to match from one router to the next, as you'll see in our Bloor config, we use a different number. It simply identifies the process number within the IOS hierarchy, and has no bearing on routing nor on packet flow. In EIGRP, the number in the router eigrp 701 was the autonomous system number and it had to match across the whole EIGRP network. With OSPF, it doesn't have to match.
Next we add our interface to the OSPFv3 process. OSPF will automatically pick up any configured prefixes (subnets) from the interface config and start sending an LSA (LSU!) to the DRs and BDRs, which are two elected routers. Let's configure the interface:
spadina#conf t
Enter configuration commands, one per line. End with CNTL/Z.
spadina(config)#int FE0/1
spadina(config-if)#ipv6 ospf 137 ?
area Set the OSPF area ID
spadina(config-if)#ipv6 ospf 137 area 0
That's all it takes to add an interface with all its subnets to OSPF for exchange. To verify we can use the show ipv6 protocols command:
spadina#show ipv6 protocols
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPV6 Routing Protocol is "ospf 137"
Interfaces (Area 0):
FastEthernet0/1
Redistribution:
None
As you can tell the interface has been added to Area 0. OSPF is a bit more efficient than EIGRP. Whereas in EIGRP we had to configure an autonomous system (AS) number for the whole network, with OSPF we configure areas to break up the network into smaller chunks. Area 0 was configured with the "area 0" keyword. It is known as the backbone area, and all other areas must be connected to it. Only a router may connect one area to another. This means that a router that connects any area to the backbone will have to be a part of both areas, and thus will require two commands for that interface with different area numbers, obviously. This type of router is called an ABR (area border router). We will not be configuring any of those, as that's a bit more advanced. Just remember that in order to speed up routing updates, the routing tables get broken up into areas, that way only routes within each area get updated and nothing from the outside. Now let's configure Bloor:
bloor(config)#ipv6 unicast-routing
bloor(config)#ipv6 router ospf 37
*Oct 22 15:08:11.518: %OSPF-4-NORTRID: OSPF process 37 cannot pick a router-id.
Please configure manually or bring up an interface with an ip address.
bloor(config-rtr)#router-id 2.2.2.2
bloor(config-rtr)#exit
bloor(config)#int FE0/1
bloor(config-if)#ipv6 ospf 37 area 0
bloor(config-if)#end
bloor#show ipv6 protocols
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPV6 Routing Protocol is "ospf 37"
Interfaces (Area 0):
FastEthernet0/1
Redistribution:
None
We've done all the same things as on Spadina. The only difference is that here we've chosen a different process ID, 37. We're being funny with these numbers just to illustrate they don't need to match, it would have made more sense in a production environment to pick something easier to troubleshoot like 1 obviously.
We've gone ahead and configured the other two routers. If we look at the output of show ipv6 ospf on the Booth router we get a lot of, mostly, useless statistics:
booth#show ipv6 ospf
Routing Process "ospf 1" with ID 4.4.4.4
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
Initial SPF schedule delay 5000 msecs
Minimum hold time between two consecutive SPFs 10000 msecs
Maximum wait time between two consecutive SPFs 10000 msecs
Incremental-SPF disabled
Minimum LSA interval 5 secs
Minimum LSA arrival 1000 msecs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 0. Checksum Sum 0x000000
Number of opaque AS LSA 0. Checksum Sum 0x000000
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Number of areas transit capable is 0
External flood list length 0
Area BACKBONE(0)
Number of interfaces in this area is 1
Area has no authentication
SPF algorithm last executed 00:00:00 ago
SPF algorithm executed 1 times
Area ranges are
Number of LSA 1. Checksum Sum 0x00A797
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
The important bit here is the first line which tells us the OSPF process number, in this case 1, and the router ID is 4.4.4.4, though the word "router" is omitted from router ID and it just says ID. The IOS is funky like that sometimes. But we still won't have any DRs, BDRs, nor routes being exchanged. This is because all of these interface configs were done on our LAN interfaces. We also need to enable OSPF on the WAN interfaces so that the LAN subnets can be exchanged. This is easily done and is nearly identical. Here is an example from Spadina:
spadina(config)#int FE0/0
spadina(config-if)#ipv6 ospf 137 area 0
OSPFv3: No IPv6 enabled on this interface.
Uh-Oh! What does this mean? I thought interfaces didn't need specific IPv6 addresses assigned to them since ULA (unique local addresses) took care of that on data-links for us. Why doesn't this interface have an FE80 address already assigned to it? Clearly without an IPv6 address, we can't enable OSPFv3 on an interface. That would be like asking for mail to be delivered to a house that hasn't been issued a street number yet.
FE80 addresses (ULAs) are only assigned by IOS when the first ipv6 address command is issued. Until then, the interface remains unassigned in the IPv6 realm and no routing protocols may be enabled. So we go ahead and assign an IPv6 address for the magic to begin:
spadina(config-if)#ipv6 address FD00:1:1:1::4/64
spadina(config-if)#ipv6 ospf 137 area 0
The rest of the routers are numbered just like in the EIGRPv6 Triangle tutorial:
Bloor
FD00:1:1:1::1
Kensington
FD00:1:1:1::2
Booth
FD00:1:1:1::3
Spadina
FD00:1:1:1::4
That's all it takes. After a short delay we get this on our consoles:
*Oct 22 15:47:04.799: %OSPF-5-ADJCHG: Process 137, Nbr 3.3.3.3 on FastEthernet0/0 from LOADING to FULL, Loading Done
*Oct 22 15:47:04.193: %OSPF-5-ADJCHG: Process 137, Nbr 4.4.4.4 on FastEthernet0/0 from LOADING to FULL, Loading Done
These two lines tell us that we have formed an adjacency with two neighbors. The Nbr part is short for Router-ID, and it tells us that routers 3.3.3.3 and 4.4.4.4 have gone from a LOADING phase, whereby the LSA are being exchanged, to a FULL state, whereby all the LSA are finished transferring. We can check our OSPFv3 neighbors to be sure:
spadina#show ipv6 ospf neighbo
Neighbor ID Pri State Dead Time Interface ID Interface
3.3.3.3 1 FULL/DR 00:00:40 3 FastEthernet0/0
2.2.2.2 1 2WAY/DROTHER 00:00:40 3 FastEthernet0/0
4.4.4.4 1 FULL/BDR 00:00:40 3 FastEthernet0/0
As you can see, we have three neighbors, but we only have full adjacencies with two of them. The router with RID 2.2.2.2 is not in a FULL state, but in a 2WAY state, which comes before FULL. This means we are not exchanging LSAs with it. The router 3.3.3.3 is the DR (as noted after the word FULL), which means it's the designated router. It's backup is the BDR, which is 4.4.4.4. In case the DR goes down, the BDR takes over. No matter how many OSPFv3 routers are on this network, there will ever only be two adjacencies, one with the DR and one with the BDR. All other routers will be in a 2WAY/DROTHER state if they are fully configured. They will still have the same routing table, but will have received it from the DR and not from each of the other routers. Basically the DR (and BDR) act as a kind of a hub in a hub and spoke network. The routers send their LSAs to the two of them, and they are in turn responsible for updating the rest of the network. This is counter to the way EIGRP works, where each router forms a neighbor relationship with every other router, which is kinda wasteful.
We can now look at the routing table:
spadina#show ipv6 route
IPv6 Routing Table
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
D - EIGRP, EX - EIGRP external
C FD00:1:1:1::/64 [0/0]
via FastEthernet0/0, directly connected
L FD00:1:1:1::4/128 [0/0]
via FastEthernet0/0, receive
C 2001:9:9:9::/64 [0/0]
via FastEthernet0/1, directly connected
L 2001:9:9:9::1/128 [0/0]
via FastEthernet0/1, receive
O 2001:1:1:1::/64 [110/2]
via FE80::20C:39FF:FE62:6232, FastEthernet0/0
O 2001:2:2:2::/64 [110/2]
via FE80::20C:31FF:FE68:8461, FastEthernet0/0
O 2001:4:4:4::/64 [110/2]
via FE80::20C:84FF:FE99:1947, FastEthernet0/0
L FF00::/8 [0/0]
via Null0, receive
All the routes that start with O on the far left are from the OSPF process. We see all the routes have made it, despite the various routers having differing process IDs. However, we see that only the 2001:4:4:4::/64 network has made it from Bloor. What happened to the rest? Well kind of like with EIGRP, we did not configure redistribute connected command, which would have inserted all the connected routes into OSPF. Without this command, IOS only can add an LSA for the first network of an interface. The rest just get ignored by the OSPF process.
Enjoy!
Monday, October 20, 2014
Setting up an EIGRPv6 triangle
A while back LIST (Latitude Internet Security Team) wanted to test out EIGRPv6 in three of their offices in Toronto. The WAN product they used was Metro Ethernet whereby all three routers appear like any other Ethernet hosts to each other, and that made matters relatively simple despite the distances involved. On the provided diagram the offices are labelled according to their physical locations. Bloor is located near Toronto's Yorkville offices on Bloor street. Booth is located on Booth Avenue just south of East Chinatown near Queen Street across the lovely Jimmie Simpson park. And the final part of the triangle is located in an office at the Kensington Market.
EIGRPv6 Neighbor addressing is as follows:
Bloor
FD00:1:1:1::1
Kensington
FD00:1:1:1::2
Booth
FD00:1:1:1::3
These will be the only addresses establishing EIGRPv6 neighbors. We use IPv6 internally, but for this test we'll be exchanging a mix of GUAs and ULAs. The addressing is as follows:
Engineering (Bloor)
2001:4:4:4::/64
2001:5:5:5::/64
2001:6:6:6::/64
2001:7:7:7::/64
FD00:8:8:8::/64
Sales (Kensington)
2001:1:1:1::/64
Support (Booth)
2001:2:2:2::/64
2001:3:3:3::/64
As you can tell our Engineering team uses the most network space followed by the Support team. Once again this addressing scheme isn't to be used in the real world as these addresses could very well be assigned to someone else by IANA, we use it here for this test only.
First we assign an IPv6 address on the Bloor router's FastEthernet0/0:
bloor(config)#int FE 0/0
bloor(config-if)#ipv6 address FD00:1:1:1::1/64
Next we do the same to Booth but we make a mistake the first time by holding down shift a bit too long, a typical error when typing IPv6 addresses quickly. This error may throw you off because IOS does not put the ^ market at the exact point where the ! is located instead of the 1:
booth(config)#int FE 0/0
booth(config-if)#ipv6 address FD00:1:1:!::3/64
^
% Invalid input detected at '^' marker.
booth(config-if)#ipv6 address FD00:1:1:1::3/64
booth(config-if)#^Z
Lastly we configure Kensington and thus establishing full IPv6 connectivity:
kensington(config)#int FE 0/0
kensington(config-if)#ipv6 address FD00:1:1:1::2/64
It's always good to test connectivity with a simple ping, so we do that from the Booth router as that's where the Support team is located. First we do an extended ping to show how that it yields the same results as a normal ping:
booth#ping
Protocol [ip]: ipv6
Target IP address: FD00:1:1:1::1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FD00:1:1:1::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent ( 5/ 5), round-trip min/avg/max = 1/2/4 ms
booth#
booth#ping FD00:1:1:1::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FD00:1:1:1::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Before configuring EIGRP we must decide on an AS (autonomous system) number for our network. As it's network wide it must match on all three routers. We use 701 internally. The command to configure EIGRP is ipv6 router eigrp 701 in this case, but as you can see something went wrong.
bloor#conf t
Enter configuration commands, one per line. End with CNTL/Z.
bloor(config)#ipv6 router eigrp ?
<1-65535> Autonomous system number
bloor(config)#ipv6 router eigrp 701
%IPv6 unicast routing not enabled.
Before any IPv6 routing protocol is enabled, unicast routing must be enabled globally in IOS. Here is the corrected config that works:
bloor(config)#ipv6 unicast-routing
bloor(config)#ipv6 router eigrp 701
bloor(config-rtr)#no shut
These commands don't produce any errors and so we enter them on all three routers. The final command, no shut, may seem strange as it's usually associated with interfaces. Cisco chose to maintain consistency when implementing this method. The EIGRP process is in a shutdown state when created with the router eigrp command, without this little guy the whole thing wouldn't provide any exchange of routes. So ensure you remember this bit.
So let's see what interfaces are exchanging EIGRP routes:
booth#show ipv6 eigrp interfaces
IPv6-EIGRP interfaces for process 701
% No router ID for EIGRP 701
Uh-oh! Here is a key problem. Although we are using IPv6 with it's 128-bit addressing, the RID (router-ID) that EIGRP (and OSPF) rely on is still a 32-bit value. A RID is required for neighbors to form, and since the IOS cannot arbitrarily create one from the 128-bit interface addresses, we must provide a value here via the config. RIDs don't have to be actual IP addresses, so we'll use 1.1.1.1 for Bloor, 2.2.2.2 for Kensington, and 3.3.3.3 for Booth. These addresses are inline with our IPv6 naming convention, thus making it easier to remember and associate during debugging of issues. We'll only show the config on Bloor, but the config is identical on the other two devices, with the obvious difference being the number placed into the config.
bloor(config)#ipv6 router eigrp 701
bloor(config-rtr)#router-id ?
a.b.c.d EIGRP Router-ID in IP address format
bloor(config-rtr)#router-id 1.1.1.1
We now run our show ipv6 eigrp interfaces command, and still we have nothing showing, but this time we don't get an error.
booth#show ipv6 eigrp interfaces
IPv6-EIGRP interfaces for process 701
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
booth#
What gives? Well, EIGRPv6 is running. But there are no indications what networks it should exchange and on what interface it should exchange them on. This is configured using the interface subcommand ipv6 eigrp 701 on all three routers. Here is an example on Bloor, but we do the same exact command on the other two routers.
bloor(config)#int FE 1/0
bloor(config-if)#ipv6 eigrp ?
<1-65535> Autonomous system number
bloor(config-if)#ipv6 eigrp 701
That has enabled the EIGRPv6 process on each of the interfaces connected to our "LAN" (aka Metro Ethernet WAN). But wait! It still won't work. How does EIGRP know what networks to advertise? How does it know on what interfaces to look for neighbors? We have to tell IOS these things specifically, it's not going to make any assumptions for us. EIGRPv6 doesn't allow for specific networks to be listed, instead it picks up the prefixes from the interfaces it is enabled on. The interface subcommand is ipv6 eigrp 701 and here is an example from Bloor. We use the exact same command on the other two routers:
bloor(config)#int FE0/0
bloor(config-if)#ipv6 eigrp 701
bloor(config-if)#^Z
%SYS-5-CONFIG_I: Configured from console by console
*Oct 20 09:12:46.929: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 701: Neighbor FE80::20C:84FF:FE99:1947 (FastEthernet0/0) is up: new adjacency
What happened there was that a moment after adding this command, as the other router was already configured with the same command, the adjacency came up and we were notified of this fact by IOS on the console. Now we can look at various EIGRP outputs. Let's look from the Booth router:
booth#show ipv6 eigrp neighbors
IPv6-EIGRP neighbors for process 701
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 Link-local address: Fa0/0 14 00:08:39 936 5616 0 4
FE80::20C:39FF:FE62:6232
1 Link-local address: Fa0/0 14 00:07:04 291 1746 0 4
FE80::20C:31FF:FE68:8461
As you can see, Booth has two neighbors. However EIGRPv6 doesn't use the FD00 addresses we've assigned the interfaces. Instead it uses a third type of address, called a link-local address (LLA). This is a self-generated address. If you look at the very middle it has FF:FE. This is part of the EUI-64 auto-addressing rule whereby the MAC address is split in half, the FF:FE is inserted in the middle, and the 7th bit from the left is inverted. This is attached to the FE80:: prefix and thus the LLA is formed. It is not routable, and only serves for communication on the local network, such as Ethernet in this case.
If we look at the routing table we see our routes as expected:
booth#show ipv6 route
IPv6 Routing Table
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
D - EIGRP, EX - EIGRP external
C FD00:1:1:1::/64 [0/0]
via FastEthernet0/0, directly connected
L FD00:1:1:1::3/128 [0/0]
via FastEthernet0/0, receive
C 2001:2:2:2::/64 [0/0]
via FastEthernet0/1, directly connected
L 2001:2:2:2::1/128 [0/0]
via FastEthernet0/1, receive
C 2001:3:3:3::/64 [0/0]
via FastEthernet0/1, directly connected
L 2001:3:3:3::1/128 [0/0]
via FastEthernet0/1, receive
D 2001:4:4:4::/64 [90/30720]
via FE80::20C:39FF:FE62:6232, FastEthernet0/0
D 2001:1:1:1::/64 [90/30720]
via FE80::20C:31FF:FE68:8461, FastEthernet0/0
L FF00::/8 [0/0]
via Null0, receive
All our routes are there. You can see the 2001:4:4:4::/64 being learned, as well as 2001:1:1:1::/64. These have a D on the left, as per the legend meaning learned via EIGRP. You might be wondering, if Bloor has more than one network, why did only the 4 network make it into EIGRP? This is because to have the rest appear in the routing tables we need to use the redistribute connected command which tells the EIGRP process to include all connected routes. Since this option wasn't enabled, all the routes won't be present.
We can look at some statistics about EIGRP traffic, too:
booth#show ipv6 eigrp traffic
IPv6-EIGRP Traffic Statistics for AS 701
Hellos sent/received: 110/106
Updates sent/received: 12/2
Queries sent/received: 14/10
Replies sent/received: 5/6
Acks sent/received: 11/5
Input queue high water mark 2, 0 drops
SIA-Queries sent/received: 0/0
SIA Replies sent/received: 0/0:
Hello Process ID: 107
PDM Process ID: 105
The relevant parts are the Hellos and perhaps Updates. If Hellos are incrementing, everything should be working smoothly.
And so our EIGRP triangle works perfectly. Aside from a few small glitches as documented above, we ran into zero problems setting this up. Enjoy your IPv6 journey.
Addressing
Since this was an internal test, all neighbor interfaces were configured using ULA (unique local addressing). GUA (global unicast addressing) could have also been used to make it routable but that wasn't a requirement, and it's a bit safer to use ULA during this type of test anyway. ULA space is FC00::/7, however RFC 4193 practically limits this range to the FD00::/8 block so all our addresses will start with FD00. While section 3.2.2 of the RFC directs us on how to choose our ULA prefix through a pseudo-random process, as our test will be run once and there won't be a feasable successor network after it (that's an EIGRP joke!) we will use the simplified prefix of FD00:1:1:1::/64 for all neighbors. This strategy should not be used in large enterprises as in case of mergers it would yield duplicate addressing problems the kind everyone would sooner avoid.EIGRPv6 Neighbor addressing is as follows:
Bloor
FD00:1:1:1::1
Kensington
FD00:1:1:1::2
Booth
FD00:1:1:1::3
These will be the only addresses establishing EIGRPv6 neighbors. We use IPv6 internally, but for this test we'll be exchanging a mix of GUAs and ULAs. The addressing is as follows:
Engineering (Bloor)
2001:4:4:4::/64
2001:5:5:5::/64
2001:6:6:6::/64
2001:7:7:7::/64
FD00:8:8:8::/64
Sales (Kensington)
2001:1:1:1::/64
Support (Booth)
2001:2:2:2::/64
2001:3:3:3::/64
As you can tell our Engineering team uses the most network space followed by the Support team. Once again this addressing scheme isn't to be used in the real world as these addresses could very well be assigned to someone else by IANA, we use it here for this test only.
Config
Before configuring EIGRPv6 we need to establish basic IPv6 connectivity, meaning all three routers need to be placed into the same prefix (subnet), and for that we've chosen FD00:1:1:1::/64.First we assign an IPv6 address on the Bloor router's FastEthernet0/0:
bloor(config)#int FE 0/0
bloor(config-if)#ipv6 address FD00:1:1:1::1/64
Next we do the same to Booth but we make a mistake the first time by holding down shift a bit too long, a typical error when typing IPv6 addresses quickly. This error may throw you off because IOS does not put the ^ market at the exact point where the ! is located instead of the 1:
booth(config)#int FE 0/0
booth(config-if)#ipv6 address FD00:1:1:!::3/64
^
% Invalid input detected at '^' marker.
booth(config-if)#ipv6 address FD00:1:1:1::3/64
booth(config-if)#^Z
Lastly we configure Kensington and thus establishing full IPv6 connectivity:
kensington(config)#int FE 0/0
kensington(config-if)#ipv6 address FD00:1:1:1::2/64
It's always good to test connectivity with a simple ping, so we do that from the Booth router as that's where the Support team is located. First we do an extended ping to show how that it yields the same results as a normal ping:
booth#ping
Protocol [ip]: ipv6
Target IP address: FD00:1:1:1::1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FD00:1:1:1::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent ( 5/ 5), round-trip min/avg/max = 1/2/4 ms
booth#
booth#ping FD00:1:1:1::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FD00:1:1:1::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Before configuring EIGRP we must decide on an AS (autonomous system) number for our network. As it's network wide it must match on all three routers. We use 701 internally. The command to configure EIGRP is ipv6 router eigrp 701 in this case, but as you can see something went wrong.
bloor#conf t
Enter configuration commands, one per line. End with CNTL/Z.
bloor(config)#ipv6 router eigrp ?
<1-65535> Autonomous system number
bloor(config)#ipv6 router eigrp 701
%IPv6 unicast routing not enabled.
Before any IPv6 routing protocol is enabled, unicast routing must be enabled globally in IOS. Here is the corrected config that works:
bloor(config)#ipv6 unicast-routing
bloor(config)#ipv6 router eigrp 701
bloor(config-rtr)#no shut
These commands don't produce any errors and so we enter them on all three routers. The final command, no shut, may seem strange as it's usually associated with interfaces. Cisco chose to maintain consistency when implementing this method. The EIGRP process is in a shutdown state when created with the router eigrp command, without this little guy the whole thing wouldn't provide any exchange of routes. So ensure you remember this bit.
So let's see what interfaces are exchanging EIGRP routes:
booth#show ipv6 eigrp interfaces
IPv6-EIGRP interfaces for process 701
% No router ID for EIGRP 701
Uh-oh! Here is a key problem. Although we are using IPv6 with it's 128-bit addressing, the RID (router-ID) that EIGRP (and OSPF) rely on is still a 32-bit value. A RID is required for neighbors to form, and since the IOS cannot arbitrarily create one from the 128-bit interface addresses, we must provide a value here via the config. RIDs don't have to be actual IP addresses, so we'll use 1.1.1.1 for Bloor, 2.2.2.2 for Kensington, and 3.3.3.3 for Booth. These addresses are inline with our IPv6 naming convention, thus making it easier to remember and associate during debugging of issues. We'll only show the config on Bloor, but the config is identical on the other two devices, with the obvious difference being the number placed into the config.
bloor(config)#ipv6 router eigrp 701
bloor(config-rtr)#router-id ?
a.b.c.d EIGRP Router-ID in IP address format
bloor(config-rtr)#router-id 1.1.1.1
We now run our show ipv6 eigrp interfaces command, and still we have nothing showing, but this time we don't get an error.
booth#show ipv6 eigrp interfaces
IPv6-EIGRP interfaces for process 701
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
booth#
What gives? Well, EIGRPv6 is running. But there are no indications what networks it should exchange and on what interface it should exchange them on. This is configured using the interface subcommand ipv6 eigrp 701 on all three routers. Here is an example on Bloor, but we do the same exact command on the other two routers.
bloor(config)#int FE 1/0
bloor(config-if)#ipv6 eigrp ?
<1-65535> Autonomous system number
bloor(config-if)#ipv6 eigrp 701
That has enabled the EIGRPv6 process on each of the interfaces connected to our "LAN" (aka Metro Ethernet WAN). But wait! It still won't work. How does EIGRP know what networks to advertise? How does it know on what interfaces to look for neighbors? We have to tell IOS these things specifically, it's not going to make any assumptions for us. EIGRPv6 doesn't allow for specific networks to be listed, instead it picks up the prefixes from the interfaces it is enabled on. The interface subcommand is ipv6 eigrp 701 and here is an example from Bloor. We use the exact same command on the other two routers:
bloor(config)#int FE0/0
bloor(config-if)#ipv6 eigrp 701
bloor(config-if)#^Z
%SYS-5-CONFIG_I: Configured from console by console
*Oct 20 09:12:46.929: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 701: Neighbor FE80::20C:84FF:FE99:1947 (FastEthernet0/0) is up: new adjacency
What happened there was that a moment after adding this command, as the other router was already configured with the same command, the adjacency came up and we were notified of this fact by IOS on the console. Now we can look at various EIGRP outputs. Let's look from the Booth router:
booth#show ipv6 eigrp neighbors
IPv6-EIGRP neighbors for process 701
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 Link-local address: Fa0/0 14 00:08:39 936 5616 0 4
FE80::20C:39FF:FE62:6232
1 Link-local address: Fa0/0 14 00:07:04 291 1746 0 4
FE80::20C:31FF:FE68:8461
As you can see, Booth has two neighbors. However EIGRPv6 doesn't use the FD00 addresses we've assigned the interfaces. Instead it uses a third type of address, called a link-local address (LLA). This is a self-generated address. If you look at the very middle it has FF:FE. This is part of the EUI-64 auto-addressing rule whereby the MAC address is split in half, the FF:FE is inserted in the middle, and the 7th bit from the left is inverted. This is attached to the FE80:: prefix and thus the LLA is formed. It is not routable, and only serves for communication on the local network, such as Ethernet in this case.
If we look at the routing table we see our routes as expected:
booth#show ipv6 route
IPv6 Routing Table
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
D - EIGRP, EX - EIGRP external
C FD00:1:1:1::/64 [0/0]
via FastEthernet0/0, directly connected
L FD00:1:1:1::3/128 [0/0]
via FastEthernet0/0, receive
C 2001:2:2:2::/64 [0/0]
via FastEthernet0/1, directly connected
L 2001:2:2:2::1/128 [0/0]
via FastEthernet0/1, receive
C 2001:3:3:3::/64 [0/0]
via FastEthernet0/1, directly connected
L 2001:3:3:3::1/128 [0/0]
via FastEthernet0/1, receive
D 2001:4:4:4::/64 [90/30720]
via FE80::20C:39FF:FE62:6232, FastEthernet0/0
D 2001:1:1:1::/64 [90/30720]
via FE80::20C:31FF:FE68:8461, FastEthernet0/0
L FF00::/8 [0/0]
via Null0, receive
All our routes are there. You can see the 2001:4:4:4::/64 being learned, as well as 2001:1:1:1::/64. These have a D on the left, as per the legend meaning learned via EIGRP. You might be wondering, if Bloor has more than one network, why did only the 4 network make it into EIGRP? This is because to have the rest appear in the routing tables we need to use the redistribute connected command which tells the EIGRP process to include all connected routes. Since this option wasn't enabled, all the routes won't be present.
We can look at some statistics about EIGRP traffic, too:
booth#show ipv6 eigrp traffic
IPv6-EIGRP Traffic Statistics for AS 701
Hellos sent/received: 110/106
Updates sent/received: 12/2
Queries sent/received: 14/10
Replies sent/received: 5/6
Acks sent/received: 11/5
Input queue high water mark 2, 0 drops
SIA-Queries sent/received: 0/0
SIA Replies sent/received: 0/0:
Hello Process ID: 107
PDM Process ID: 105
The relevant parts are the Hellos and perhaps Updates. If Hellos are incrementing, everything should be working smoothly.
And so our EIGRP triangle works perfectly. Aside from a few small glitches as documented above, we ran into zero problems setting this up. Enjoy your IPv6 journey.
Subscribe to:
Comments (Atom)