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.
No comments:
Post a Comment