Internetwork Expert Volume II: Lab 12 – Section 7

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>

ipv6 rip metric-offset

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