True Confession: I wanted to start with EIGRP for IPv6, but it isn't supported on either of the routers I have available in GNS3, grrr... However, RIPng is, so we'll go with RIPng for now. I now return you to your regularly scheduled blog post...
Here's the network I am using for this lab:
We start by enabling unicast routing on the routers, and assigning the IPv6 addresses to all of the interfaces (R1 shown, others similar):
R1(config)#ipv6 unicast-routing
R1(config)#int lo0
R1(config-if)#ip addr 10.254.254.1 255.255.255.255
R1(config-if)#ipv6 enable
R1(config-if)#ipv6 address 2001:00C0:FFEE:0000:0000:0000:0000:1/128
R1(config-if)#no shut
R1(config-if)#int fa0/0
R1(config-if)#ipv6 enable
R1(config-if)#ipv6 address 2001:00C0:FFEE:0000:0000:0000:0001:0001/125
R1(config-if)#no shut
R1(config-if)#int s/0/0
R1(config-if)#ipv6 enable
R1(config-if)#ipv6 address 2001:00C0:FFEE:0000:0000:0000:1111:0001/126
R1(config-if)#no shut
Once you have assigned IPv6 addresses to the respective interfaces on all of the routers, you should be able to ping across each subnet, but (for example) R5 shouldn't be able to ping R4:
R5(config)#do ping 2001:C0:FFEE::2222:1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:C0:FFEE::2222:1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/9/16 ms
R5(config)#do ping 2001:C0:FFEE::1111:2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:C0:FFEE::1111:2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R5(config)#
This is not at all unexpected. In IPv4, you wouldn't be able to ping from R5 to R4 either, unless you had static routes in place or a routing protocol to create the routes between routers that are not directly connected. Let's turn up RIPng on all five routers to share routes across this network (again, R1 shown, but the other routers are similar):
R1(config)#int fa0/0
R1(config-if)#ipv6 rip 10 enable
R1(config-if)#int s0/0
R1(config-if)#ipv6 rip 10 enable
R1(config-if)#exit
That's it! No "network" statements -- just edit the interface configuration to tell the router to start the RIPng process on that interface, and the router will begin sending advertisements for connected networks through that interface. Let's look at the routing table on R1:
R1(config)#do sho ipv6 route
IPv6 Routing Table - 8 entries
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
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
LC 2001:C0:FFEE::1/128 [0/0]
via ::, Loopback0
C 2001:C0:FFEE::1:0/125 [0/0]
via ::, FastEthernet0/0
L 2001:C0:FFEE::1:1/128 [0/0]
via ::, FastEthernet0/0
C 2001:C0:FFEE::1111:0/126 [0/0]
via ::, Serial0/0
L 2001:C0:FFEE::1111:1/128 [0/0]
via ::, Serial0/0
R 2001:C0:FFEE::2222:0/126 [120/2]
via FE80::CA01:33FF:FE30:0, FastEthernet0/0
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0
R1(config)#
Hmmm...notice that the loopback interfaces for R2 through R5 aren't showing up? Let's edit R1 and R2 to see if enabling RIPng on the loopback interfaces resolves that problem:
R1(config)#int lo0
R1(config-if)#ipv6 rip 10 enable
R1(config-if)#exit
...
R2(config)#int lo0
R2(config-if)#ipv6 rip 10 enable
R2(config-if)#exit
Does R1 see the loopback address on R2 now?
R1(config)#do sho ipv6 route | inc 2001:C0:FFEE::2/128
R 2001:C0:FFEE::2/128 [120/2]
R1(config)#
Yep, that works...but is there a better way to enable RIPng on an interface that isn't actually connected to another host? Let's try something on R3:
R3(config)#ipv6 router rip 10
R3(config-rtr)#redist connected
Does R1 see R3's loopback now?
R1(config)#do sho ipv6 route | inc 2001:C0:FFEE::3/128
R 2001:C0:FFEE::3/128 [120/2]
R1(config)#
Success! On the downside, it's a little hokey that you enable RIPng on the interface, but have to enable redistribution of connected routes in a global configuration, but I suppose that's better than having to enable redistribution on each interface <shrug>
One other thing to look at: let's look at one other thing in the routing table on R1:
R1(config)#do sho ipv6 route
IPv6 Routing Table - 8 entries
<...snip...>
L FF00::/8 [0/0]
via ::, Null0
R1(config)#
Once again, there is an odd-looking IPv6 address showing up in the routing table. Let's check our interfaces for anything similar:
R1(config)#do sho ipv6 int brie | inc FF00
R1(config)#
No...nothing there. What gives?
As it turns out, FF02::9 is a multicast address reserved by IANA for RIPng route updates, as defined in RFC 2080. And with that interesting (?) little tidbit of information, we will wrap up this lab on IPv6 routing with RIPng. Next time, we'll dive into OSPFv3.
No comments:
Post a Comment