Chapter 9: OSPFv3

Cisco Press

1 2 3 4 5 Page 4
Page 4 of 5

Note that the network type is BROADCAST. Also note that the neighbor count is 3, and there are 3 adjacent neighbors. This router is the DR, so it has become adjacent to all other routers on the network. The neighbors that are not DR or BDR, such as Flobberworm, have three neighbors, but only two adjacent neighbors, as shown in Example 9-15, because routers on broadcast networks become adjacent to the DR and BDR only.

Example 9-15 With four routers on a broadcast network, a non-DR or BDR router will have three neighbors, but only be fully adjacent to two of the neighbors.

Flobberworm#show ipv6 ospf neighbor

Neighbor ID   Pri  State      Dead Time  Interface ID  Interface
1.1.1.1     20  FULL/DR     00:00:36  3        Ethernet0/0
10.1.1.23     1  2WAY/DROTHER  00:00:36  3        Ethernet0/0
10.1.3.1     15  FULL/BDR    00:00:37  3        Ethernet0/0
Flobberworm#

To avoid the DR/BDR election process, the OSPF network type can be changed to point-to-multipoint, as can be seen in Skrewt's modified configuration in Example 9-16.

Example 9-16 Skrewt's configuration shows that the PVCs continue to broadcast, and that the OSPFv3 network type has been changed to point-to-multipoint.

Interface Serial 0/0
 encapsulation frame-relay
 ipv6 address 2001:DB8:0:1::1/64
 ipv6 ospf network point-to-multipoint
 ipv6 ospf 1 area 1
 ipv6 ospf priority 20
 frame-relay map ipv6 fe80::206:28ff:feb6:5bc0 201 broadcast
 frame-relay map ipv6 fe80::202:fdff:fe5a:e40 202 broadcast
 frame-relay map ipv6 fe80::201:42ff:fe79:e500 203 broadcast

Skrewt's IPv6 OSPF interface configuration (Example 9-17) shows that the default timers are different for point-to-multipoint networks then they are for broadcast networks. Hellos are sent every 30 seconds on point-to-multipoint networks and every 10 seconds on broadcast networks. The OSPFv3 interface configuration also does not show any DR, and the router is adjacent with all three neighbors.

Example 9-17 The IPv6 OSPF interface configuration of an OSPF point-to-multipoint network is displayed with the command show ipv6 ospf interface.

Skrewt#show ipv6 ospf interface serial 0/0
Serial0/0 is up, line protocol is up
 Link Local Address FE80::207:85FF:FE6B:EA20, Interface ID 4
 Area 1, Process ID 1, Instance ID 0, Router ID 1.1.1.1
 Network Type POINT_TO_MULTIPOINT, Cost: 64
 Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT,
 Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
  Hello due in 00:00:13
 Index 1/1/1, flood queue length 0
 Next 0x0(0)/0x0(0)/0x0(0)
 Last flood scan length is 2, maximum is 4
 Last flood scan time is 0 msec, maximum is 4 msec
 Neighbor Count is 3, Adjacent neighbor count is 3
  Adjacent with neighbor 10.1.1.23
  Adjacent with neighbor 10.1.3.1
  Adjacent with neighbor 192.2.2.9
 Suppress hello for 0 neighbor(s)
Skrewt#

An NBMA network configured as an OSPF point-to-multipoint network need not have a full mesh of underlying PVCs. Figure 9-18 shows that some PVCs have been removed from the network in Figure 9-17. The map statement for DLCI 202 has been removed from Skrewt in Example 9-18.

Figure 9-18

Figure 9-18Figure 9-17, with some PVCs removed.

The network of

Example 9-18 Skrewt's Frame Relay configuration maps IPv6 addresses to the remaining two PVCs.

interface Serial0/0
 no ip address
 encapsulation frame-relay
 ipv6 address 2001:DB8:0:1::1/64
 ipv6 ospf network point-to-multipoint
 ipv6 ospf priority 20
 ipv6 ospf 1 area 1
 frame-relay map ipv6 FE80::201:42FF:FE79:E500 203 broadcast
 frame-relay map ipv6 FE80::206:28FF:FEB6:5BC0 201 broadcast

Hippogriff and the IPv6 prefixes known to Hippogriff are all accessible from Skrewt, as can be seen in Skrewt's IPv6 route table shown in Example 9-19. Skrewt and Hippogriff are both adjacent to both Thestral and Flobberworm, and Hippogriff's IPv6 serial0/0 IPv6 address, 2001:db8:0:1::3, in addition to the IPv6 prefixes advertised by Hippogriff, are routed to via Skrewt's serial0/0 interface, and to the next-hop link-local addresses FE80::206: 28FF:FEB6:5BC0 and FE80::201:42FF:FE79:E500.

Example 9-19 Skrewt's route table shows that even the router that does not have a connected PVC to Skrewt is still accessible via the routers that do have connected PVCs in the point-to-multipoint network.

Skrewt#show ipv6 route
IPv6 Routing Table - 16 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
C  2001:DB8:0:1::/64 [0/0]
   via ::, Serial0/0
L  2001:DB8:0:1::1/128 [0/0]
   via ::, Serial0/0
O  2001:DB8:0:1::2/128 [110/64]
   via FE80::206:28FF:FEB6:5BC0, Serial0/0
O  2001:DB8:0:1::3/128 [110/128]
   via FE80::206:28FF:FEB6:5BC0, Serial0/0
   via FE80::201:42FF:FE79:E500, Serial0/0
O  2001:DB8:0:1::4/128 [110/64]
   via FE80::201:42FF:FE79:E500, Serial0/0
O  2001:DB8:0:5::/64 [110/74]
   via FE80::206:28FF:FEB6:5BC0, Serial0/0
O  2001:DB8:0:A::/64 [110/138]
   via FE80::206:28FF:FEB6:5BC0, Serial0/0
   via FE80::201:42FF:FE79:E500, Serial0/0
O  2001:DB8:0:B::/64 [110/138]
   via FE80::206:28FF:FEB6:5BC0, Serial0/0
   via FE80::201:42FF:FE79:E500, Serial0/0
O  2001:DB8:0:C::/64 [110/138]
   via FE80::206:28FF:FEB6:5BC0, Serial0/0
   via FE80::201:42FF:FE79:E500, Serial0/0
O  2001:DB8:0:D::/64 [110/138]
   via FE80::206:28FF:FEB6:5BC0, Serial0/0
   via FE80::201:42FF:FE79:E500, Serial0/0
O  2001:DB8:0:50::/64 [110/74]
   via FE80::206:28FF:FEB6:5BC0, Serial0/0
O  2001:DB8:0:51::/64 [110/74]
   via FE80::206:28FF:FEB6:5BC0, Serial0/0
O  2001:DB8:0:52::/64 [110/74]
   via FE80::206:28FF:FEB6:5BC0, Serial0/0
O  2001:DB8:0:53::/64 [110/74]
   via FE80::206:28FF:FEB6:5BC0, Serial0/0
L  FE80::/10 [0/0]
   via ::, Null0
L  FF00::/8 [0/0]
   via ::, Null0
Skrewt#

The IPv6 addresses 2001:db8:0:1::2/64, 2001:db8:0:1::3/64, and 2001:db8:0:1::4/64, that have been configured on the Frame Relay point-to-multipoint interfaces are all advertised by OSPF with 128-bit prefix lengths. These addresses, along with the other IPv6 prefixes advertised by Hippogriff into OSPF, are reachable via the link-local addresses of Skrewt's two adjacent routers.

Troubleshooting OSPFv3

Troubleshooting OSPFv3 for IPv6 should be handled in the same way as OSPFv2 for IPv4. The major difference will be the addressing: OSPFv3 uses the link-local addresses as the source and, when sending directly to a neighbor, destination of packets.

Case Study: Frame Relay Mapping

Upon initial configuration of Figure 9-17, Skrewt and Hippogriff are configured with the configurations in Example 9-20 and Example 9-21.

Example 9-20 Skrewt's initial Frame Relay mapping configuration.

interface Serial 0/0
 encapsulation frame-relay
 ipv6 address 2001:DB8:0:1::1/64
 ipv6 ospf network broadcast
 ipv6 ospf 1 area 1
 frame-relay map ipv6 2001:db8:0:1::2 201 broadcast
 frame-relay map ipv6 2001:db8:0:1::3 202 broadcast
 frame-relay map ipv6 2001:db8:0:1::4 203 broadcast
 ipv6 ospf 1 area 1

Example 9-21 Hippogriff's initial Frame Relay mapping configuration.

interface Serial0/0
 no ip address
 encapsulation frame-relay
 ipv6 address 2001:DB8:0:1::3/64
 ipv6 ospf network broadcast
 ipv6 ospf 1 area 1
 frame-relay map ipv6 2001:DB8:0:1::1 220 broadcast
 frame-relay map ipv6 2001:DB8:0:1::2 221 broadcast
 frame-relay map ipv6 2001:DB8:0:1::4 223 broadcast

The other routers are configured similarly.

The routers are not becoming adjacent, as shown in Skrewt's OSPFv3 neighbor table in Example 9-22.

Example 9-22 Skrewt is not becoming adjacent to the DR or BDR.

Skrewt#show ipv6 ospf neighbor

Neighbor ID   Pri  State      Dead Time  Interface ID  Interface
10.1.3.1     1  EXSTART/DR   00:00:34  4        Serial0/0
10.1.1.23     1  EXSTART/BDR   00:00:31  4        Serial0/0
192.2.2.9     1  2WAY/DROTHER  00:00:36  4        Serial0/0
Skrewt#

Debugging IPv6 OSPF Hellos and adjacencies, Example 9-23, show that Hellos are being received and two-way communication is established. The DR and BDR are elected. Database synchronization is attempted to complete the adjacencies with the DR and BDR. Skrewt attempts to send database description packets (DBD) to the potential DR, but never receives an acknowledgment, although Skrewt does continue to receive Hellos from the potential DR. The neighbor state EXSTART with the DR and BDR indicates that a master/slave relationship is being established and an initial DBD packet has been sent.

Example 9-23 debug ipv6 ospf hello and debug ipv6 ospf adj show Hellos, two-way communication establishment, DR/BDR election, and the sending of DBD packets.

Skrewt#debug ipv6 ospf hello
Skrewt#debug ipv6 ospf adj
OSPFv3: Rcv hello from 10.1.1.23 area 1 from Serial0/0 FE80::202:FDFF:FE5A:E40 interface ID 4
OSPFv3: 2 Way Communication to 10.1.1.23 on Serial0/0, state 2WAY
OSPFv3: Neighbor change Event on interface Serial0/0
OSPFv3: DR/BDR election on Serial0/0
OSPFv3: Elect BDR 10.1.1.23
OSPFv3: Elect DR 10.1.1.23
    DR: 10.1.1.23 (Id)  BDR: 10.1.1.23 (Id)
OSPFv3: Send DBD to 10.1.1.23 on Serial0/0 seq 0xF78 opt 0x0013 flag 0x7 len 28
OSPFv3: Rcv hello from 10.1.3.1 area 1 from Serial0/0 FE80::201:42FF:FE79:E500 interface ID 4
OSPFv3: 2 Way Communication to 10.1.3.1 on Serial0/0, state 2WAY
OSPFv3: Neighbor change Event on interface Serial0/0
OSPFv3: DR/BDR election on Serial0/0
OSPFv3: Elect BDR 10.1.1.23
OSPFv3: Elect DR 10.1.3.1
    DR: 10.1.3.1 (Id)  BDR: 10.1.1.23 (Id)
OSPFv3: Send DBD to 10.1.3.1 on Serial0/0 seq 0x1C93 opt 0x0013 flag 0x7 len 28
OSPFv3: Remember old DR 10.1.1.23 (id)
OSPFv3: End of hello processing
OSPFv3: Send DBD to 10.1.1.23 on Serial0/0 seq 0xF78 opt 0x0013 flag 0x7 len 28
OSPFv3: Retransmitting DBD to 10.1.1.23 on Serial0/0 [1]
OSPFv3: Send DBD to 10.1.3.1 on Serial0/0 seq 0x1C93 opt 0x0013 flag 0x7 len 28
OSPFv3: Retransmitting DBD to 10.1.3.1 on Serial0/0 [1]
OSPFv3: Send DBD to 10.1.1.23 on Serial0/0 seq 0xF78 opt 0x0013 flag 0x7 len 28
OSPFv3: Retransmitting DBD to 10.1.1.23 on Serial0/0 [2]
OSPFv3: Rcv hello from 10.1.1.23 area 1 from Serial0/0 FE80::202:FDFF:FE5A:E40 interface ID 4
OSPFv3: End of hello processing
Skrewt#

No acknowledgments are being received. Adding a debug of IPv6 OSPF packets shows additional information about the DBD packets being sent[3] (Example 9-24).

Example 9-24 Adding debug ipv6 ospf packet shows packet encapsulation failures.

Skrewt#debug ipv6 ospf packet
OSPFv3: Send DBD to 10.1.1.23 on Serial0/0 seq 0x2422 opt 0x0013 flag 0x7 len 28
IPV6: source FE80::207:85FF:FE6B:EA20 (local)
    dest FE80::202:FDFF:FE5A:E40 (Serial0/0)
    traffic class 224, flow 0x0, len 68+0, prot 89, hops 1, originating
 IPv6: Encapsulation failed
OSPFv3: Retransmitting DBD to 10.1.1.23 on Serial0/0 [4]

The DBD packets are not multicast, as Hellos are. They are sent to the IPv6 address of the neighbor router. Recall that OSPFv3 uses the link-local addresses for packet exchange, as can be seen in the output of the IPv6 packet debug. Skrewt does not have a Frame Relay map to FE80::202:FDFF:FE5A:E40 on interface Serial0/0. This is why the encapsulation failed. Frame Relay maps must be configured mapping the link-local address of the neighbor routers to the local DLCI.

To easily obtain the link-local addresses of an IPv6 interface, use show ipv6 interface serial0/0, as shown in Example 9-25.

Example 9-25 IPv6 information pertinent to an interface can be viewed with the command show ipv6 interface.

Skrewt#show ipv6 interface serial0/0
Serial0/0 is up, line protocol is up
 IPv6 is enabled, link-local address is FE80::207:85FF:FE6B:EA20
 Global unicast address(es):
  2001:DB8:0:1::1, subnet is 2001:DB8:0:1::/64
 Joined group address(es):
  FF02::1
  FF02::2
  FF02::5
  FF02::1:FF00:1
  FF02::1:FF6B:EA20
 MTU is 1500 bytes
 ICMP error messages limited to one every 100 milliseconds
 ICMP redirects are enabled
 ND DAD is not supported
 ND reachable time is 30000 milliseconds
 Hosts use stateless autoconfig for addresses.
Skrewt#

Skrewt's and Hippogriff's configurations are changed as displayed in Example 9-26 and Example 9-27.

Example 9-26 Skrewt's Frame Relay mapping statements are changed to the link-local IPv6 addresses.

interface Serial0/0
 encapsulation frame-relay
 ipv6 address 2001:DB8:0:1::1/64
 ipv6 ospf network broadcast
 ipv6 ospf 1 area 1
 frame-relay map ipv6 fe80::206:28ff:feb6:5bc0 201 broadcast
 frame-relay map ipv6 fe80::202:fdff:fe5a:e40 202 broadcast
 frame-relay map ipv6 fe80::201:42ff:fe79:e500 203 broadcast

Example 9-27 Hippogriff's Frame Relay mapping statements are changed to the IPv6 link-local addresses.

interface Serial0/0
 no ip address
 encapsulation frame-relay
 ipv6 address 2001:DB8:0:1::3/64
 ipv6 ospf network broadcast
 ipv6 ospf 1 area 1
frame-relay map ipv6 fe80::207:85ff:fe6b:ea20 220 broadcast
frame-relay map ipv6 fe80::206:28ff:feb6:5bc0 221 broadcast
frame-relay map ipv6 fe80::201:42ff:fe79:e500 223 broadcast

The IPv6 address that must be mapped to the DLCI is the neighbor's link-local address. Skrewt's correct IPv6 OSPF neighbor table is shown in Example 9-28.

Example 9-28 After mapping the neighbors' link-local addresses to the local DLCIs, Skrewt is fully adjacent to the DR and BDR.

Skrewt#show ipv6 ospf neighbor

Neighbor ID   Pri  State      Dead Time  Interface ID  Interface
192.2.2.9     1  FULL/DR     00:00:32  4        Serial0/0
10.1.1.23     1  2WAY/DROTHER  00:00:37  4        Serial0/0
10.1.3.1     1  FULL/BDR    00:00:38  4        Serial0/0
Skrewt#

Looking Ahead

We have spent two chapters—one of them very long—describing the major aspects of OSPF, which is not only the most well-known of the link-state routing protocols, but probably the most widely used IP routing protocol. In the next chapter we will look at a less-known link-state protocol: IS-IS. Some might call this a "more exotic" protocol, but as you will see, it is actually much simpler than OSPF.

Related:
1 2 3 4 5 Page 4
Page 4 of 5
SD-WAN buyers guide: Key questions to ask vendors (and yourself)