Section 7 – IPv6 – 16 Points
7.1 IPv6 Addressing
Very basic IPv6 addressing task. The only confusing bit:
“Use the address 2001:CC1E:X:3::Y/64 for r3’s Ethernet interface.”
Ummm…r3 has TWO Ethernet interfaces? Which one do they mean? It turns out that they only mean e0/0 (VLAN3).
7.2 IPv6 over Frame Relay
This is a basic IPv6 Frame Relay hub-and-spoke task. They even go so far as to tell you what to use for the link-local addresses. I always read ahead in the IPv6 section to see if we will be running an IPv6 IGP over the Frame Relay network. In this case task 7.4 will require exactly that. SO….if there are no requirements against it, I hardset the link-local addresses to Fe80::Y (where Y is the router number) AND I go ahead and create frame maps for the link-local addresses. It’s not required in this task, but we might as well do it now.
R1 (spoke) before:
Rack16R1(config-if)#do sh run int s0/0 | i face|add|rame
interface Serial0/0
ip address 129.16.124.1 255.255.255.0
encapsulation frame-relay
frame-relay map ip 129.16.124.2 104
frame-relay map ip 129.16.124.4 104 broadcast
no frame-relay inverse-arp
R1 after:
Rack16R1(config-if)#do sh run int s0/0 | i face|add|rame
interface Serial0/0
ip address 129.16.124.1 255.255.255.0
encapsulation frame-relay
ipv6 address 2001:CC1E:16:124::1/64
ipv6 address FE80::1 link-local
frame-relay map ipv6 FE80::2 104
frame-relay map ipv6 FE80::4 104
frame-relay map ipv6 2001:CC1E:16:124::2 104
frame-relay map ipv6 2001:CC1E:16:124::4 104 broadcast
frame-relay map ip 129.16.124.2 104
frame-relay map ip 129.16.124.4 104 broadcast
no frame-relay inverse-arp
7.3 RIPng
This is a simple RIPng task.
“Configure r2 so that RIPng routes learned from BB2 with a mask longer than /64 will not be passed on to r3.”
Here are the RIPng routes that we’re receiving from BB2:
Rack16R2#sh ipv6 route rip
IPv6 Routing Table – 12 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, 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
R 2001:205:90:31::/64 [120/2]
via FE80::200:CFF:FE4A:689C, FastEthernet0/0
R 2001:220:20:3::/64 [120/2]
via FE80::200:CFF:FE4A:689C, FastEthernet0/0
R 2001:222:22:2::/64 [120/2]
via FE80::200:CFF:FE4A:689C, FastEthernet0/0
R 2001:CC1E:16:3::/64 [120/2]
via FE80::206:D7FF:FEBD:1741, Serial0/1
We need to filter some routes. Our old filtering friends from RIPv1/2 are still available although the offset-list has been moved to the interface level and renamed:
Rack16R2(config)#ipv6 router rip RIPng
Rack16R2(config-rtr)#?
distance Administrative distance
distribute-list Filter networks in routing updates
Rack16R2(config-if)#ipv6 rip RIPng ?
metric-offset Adjust default metric increment
Well…the metric-offset is not quite as flexible as the old skool offset-list because you can’t specify the routes to offset. It’s an “all or nothing” solution:
Rack16R2(config-if)#ipv rip RIPng metric-offset 16 ?
<cr>
Let’s use a distribute list instead:
distribute-list prefix-list (IPv6 RIP)
The first thing that we need to do is write an IPv6 prefix-list to match any IPv6 routes that are /64 or less:
Rack16R2(config)#ipv6 prefix-list TASK_7_2 perm 0::0/0 le 64
Then apply the distribute-list under the RIPng process:
Rack16R2(config)#ipv6 router rip RIPng
Rack16R2(config-rtr)#distribute-list prefix-list TASK_7_2 out s0/1
Since we don’t have any routes greater than /64 coming from BB2, there is really no good way to validate this. BUT make sure that the this doesn’t break your IPv6 routing by making sure that the RIPng routes from BB2 are getting to r3:
Rack16R3#sh ipv route rip
IPv6 Routing Table – 10 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, 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
R 2001:192:10:16::/64 [120/2]
via FE80::211:92FF:FE17:C860, Serial1/3
R 2001:205:90:31::/64 [120/3]
via FE80::211:92FF:FE17:C860, Serial1/3
R 2001:220:20:3::/64 [120/3]
via FE80::211:92FF:FE17:C860, Serial1/3
R 2001:222:22:2::/64 [120/3]
via FE80::211:92FF:FE17:C860, Serial1/3
7.4 OSPFv3
OSPFv3 is enabled under the interface as well:
Rack16R2(config)#int s0/0
Rack16R2(config-if)#ipv os 666 area 0
If you did not create frame maps for the link-local addresses then you will need to do this now (IPv6 IGPs use the link-local address for next-hop processing).
We need to get our neighbor adjacencies up, but we’re not allowed to change the default OSPF type. This means we need neighbor statements on the hub (and priority 0 statements on the spokes). The only deviation form the OSPFv2 process is that this is done under the interface:
Rack16R4(config-rtr)#int s0/0.124
Rack16R4(config-subif)#ipv6 ospf ?
<1-65535> Process ID
authentication Enable authentication
cost Interface cost
database-filter Filter OSPF LSA during synchronization and flooding
dead-interval Interval after which a neighbor is declared dead
demand-circuit OSPF demand circuit
flood-reduction OSPF Flood Reduction
hello-interval Time between HELLO packets
mtu-ignore Ignores the MTU in DBD packets
neighbor OSPF neighbor
network Network type
priority Router priority
retransmit-interval Time between retransmitting lost link state
advertisements
transmit-delay Link state transmit delay
Rack16R4(config-subif)#ipv6 ospf neigh 2001:CC1E:16:124::2
OSPFv3: Neighbor address needs to be a link-local address
Doh!
Rack16R4(config-subif)#ipv6 ospf neigh FE80::2
Rack16R4(config-subif)#ipv6 ospf neigh FE80::1
Rack16R4#sh ipv os neigh
Neighbor ID Pri State Dead Time Interface ID Interface
150.16.1.1 0 FULL/DROTHER 00:01:42 5 Serial0/0.124
150.16.2.2 0 FULL/DROTHER 00:01:32 5 Serial0/0.124
7.5 OSPv3
Create two new OSPFv3 areas and:
“r6 should see only one router for both the Frame Relay segment and VLAN 17 of r1.”
Here’s what we see on r6 right now:
Rack16R6#sh ipv route os
IPv6 Routing Table – 6 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, 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
OI 2001:CC1E:16:1::/64 [110/66]
via FE80::207:EFF:FE9C:F4C2, FastEthernet0/0
OI 2001:CC1E:16:124::/64 [110/65]
via FE80::207:EFF:FE9C:F4C2, FastEthernet0/0
So…is the task asking us to summarize these two routes or is it asking for a single default route? I would ask the proctor on this one.
Since making this a totally-stubby area is the easier solution, that’s the one I chose. 🙂 IE also went this route.
Rack16R4(config-if)#ipv6 router ospf 666
Rack16R4(config-rtr)#area 2 stub no-summ
Rack16R6(config)#ipv6 router ospf 666
Rack16R6(config-rtr)#area 2 stub
Rack16R6#sh ipv route os
IPv6 Routing Table – 5 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, 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
OI ::/0 [110/2]
via FE80::207:EFF:FE9C:F4C2, FastEthernet0/0
7.6 IPv6 Redistribution
Oh fun. 🙂 At least there are only two IPv6 protocols and one point of redistribution (r2).
I tried to build a TCL script and quickly found out that there is no ‘show ipv6 alias” command. 😦 I just did a “show ipv6 int brief” and copied the addresses:
foreach x {
2001:CC1E:16:1::1
2001:CC1E:16:124::1
2001:CC1E:16:3::3
2001:CC1E:16:23::3
2001:192:10:16::2
2001:CC1E:16:124::2
2001:CC1E:16:23::2
2001:CC1E:16:124::4
2001:CC1E:16:46::4
2001:CC1E:16:46::6
2001:222:22:2::1} {ping $x re 2}
The redistribution is pretty straight-forward except I couldn’t decide if I needed “include-connected” as well. I voted “no” – which ended up being a mistake. I need to review IPv6 redistribution to find out why.
Rack16R2(config-rtr)#ipv6 router ospf 666
Rack16R2(config-rtr)#redistribute rip RIPng include-conn
Rack16R2(config-rtr)#ipv6 router rip RIPng
Rack16R2(config-rtr)#redist ospf 666 metric 1 include-conn
Rack16R1#sh ipv route os
IPv6 Routing Table – 13 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, 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
OE2 2001:192:10:16::/64 [110/20]
via FE80::2, Serial0/0
OE2 2001:205:90:31::/64 [110/20]
via FE80::2, Serial0/0
OE2 2001:220:20:3::/64 [110/20]
via FE80::2, Serial0/0
OE2 2001:222:22:2::/64 [110/20]
via FE80::2, Serial0/0
OE2 2001:CC1E:16:3::/64 [110/20]
via FE80::2, Serial0/0
OE2 2001:CC1E:16:23::/64 [110/20]
via FE80::2, Serial0/0
OI 2001:CC1E:16:46::/64 [110/74]
via FE80::4, Serial0/0
Hi cciepursuit,
When doing IPv6 task 7.2, I added ‘broadcast’ keyword on the FRAME-RELAY MAP statements on the spoke routers (R1 & R2) for BOTH the FE80::x (Link-Local) AND the 2001:CC1E:X:124::Y (Global Unicast Address) target addresses of the hub router (R4) – and from the hub side put in corresponding mappings to the spokes.
However, looking at the SG, IE have used the ‘broadcast’ keyword on the frame-relay map statements for the FE80::x (Link-Local) target addresses ONLY.
Any thoughts on why the ‘broadcast’ keyword is NOT used in the IE SG for the frame-relay map statements for the 2001:CC1E:X:124::Y (GUA) target addresses??
Damian
Comment by Damian Conroy — June 16, 2009 @ 4:16 am |