Get Unlimited Access to 799 Cisco Lessons Now Get $1 Trial
You are here: Home » Cisco » CCNP TSHOOT

Troubleshooting IPv6 OSPFv3 Neighbor Adjacencies

In this lesson we’ll take a look at some OSPFv3 neighbor adjacency issues. Most of what you learned about OSPFv2 for IPv4 also applies to OSPFv3. Let’s take a look at the first issue!

OSPFv3 Router ID

I will use the following topology:

In the topology above we have 2 routers and there’s only a single area. For some reason the two routers are unable to become OSPF neighbors, up to us to find out why! Let’s check the interfaces first:

R1#show ipv6 interface brief 
FastEthernet0/0            [up/up]
    FE80::CE00:1BFF:FE29:0
R2#show ipv6 interface brief 
FastEthernet0/0            [up/up]
    FE80::CE01:1BFF:FE29:0

IPv6 routing protocols use the link-local addresses for neighbor adjacency and next-hops. We can see that both interfaces have a link-local IPv6 address and are active (up/up). Just in case, let’s ping the other side just to be sure that we have connectivity:

R1#ping FE80::CE01:1BFF:FE29:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE01:1BFF:FE29:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE00:1BFF:FE29:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/4/8 ms

No issues there, let’s continue by checking OSPFv3:

R1#show ipv6 protocols 
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPv6 Routing Protocol is "ospf 1"
  Interfaces (Area 0):
    FastEthernet0/0 
R2#show ipv6 protocols 
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPv6 Routing Protocol is "ospf 1"
  Interfaces (Area 0):
    FastEthernet0/0

OSPFv3 is running on the FastEthernet0/0 interfaces of R1 and R2. No issues there, let’s check if we have neighbors or not:

R1#show ipv6 ospf neighbor  
%OSPFv3: Router process 1 is INACTIVE, please configure a router-id
R2#show ipv6 ospf neighbor 
%OSPFv3: Router process 1 is INACTIVE, please configure a router-id

This command reveals it all. We find out that the router-id has not been configured. OSPFv3 requires an IPv4 address-style router-ID and we need to configure it ourselves. Let’s do that:

R1(config-rtr)#router-id ?
  A.B.C.D  OSPF router-id in IP address format

R1(config-rtr)#router-id 1.1.1.1
R2(config)#ipv6 router ospf 1
R2(config-rtr)#router-id 2.2.2.2

The router-ID has to be an IPv4 address format. I have no idea why they decided to do it this way for OSPFv3 but my best guess is someone got a bit nostalgic. Anyway this fixes the issue:

R1# %OSPFv3-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/0 from LOADING to FULL, Loading Done
R2# %OSPFv3-5-ADJCHG: Process 1, Nbr 1.1.1.1 on FastEthernet0/0 from LOADING to FULL, Loading Done

After configuring the router-ID we almost immediately see a message that the OSPFv3 neighbor adjacency has been established. Let’s verify this:

R1#show ipv6 ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
2.2.2.2           1   FULL/DR         00:00:33    4           FastEthernet0/0
R2#show ipv6 ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
1.1.1.1           1   FULL/BDR        00:00:31    4           FastEthernet0/0

Problem solved!

Lesson learned: Make sure you configure a router-ID for OSPFv3.

OSPFv3 Hello Packet Mismatch

Let’s look at another issue, same topology:

IPv6 OSPFv3 Two Routers Area 0

R1 and R2 are once again unable to form an OSPFv3 neighbor adjacency. Let’s check a couple of things:

R1#show ipv6 interface brief 
FastEthernet0/0            [up/up]
    FE80::CE00:1BFF:FE29:0
R2#show ipv6 interface brief 
FastEthernet0/0            [up/up]
    FE80::CE01:1BFF:FE29:0

The interfaces and IPv6 addresses are fine. Let’s do a quick ping:

R1#ping FE80::CE01:1BFF:FE29:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE01:1BFF:FE29:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE00:1BFF:FE29:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/4/8 ms

Pinging each other is no issue. Is OSPFv3 running?

R1#show ipv6 protocols 
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPv6 Routing Protocol is "ospf 1"
  Interfaces (Area 0):
    FastEthernet0/0
R2#show ipv6 protocols 
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPv6 Routing Protocol is "ospf 1"
  Interfaces (Area 0):
    FastEthernet0/0

OSPFv3 has been enabled on the interfaces, still we don’t have any neighbors:

R1#show ipv6 ospf neighbor 

R2#show ipv6 ospf neighbor

Unfortunately we don’t have any neighbors. Let’s enable a debug:

R1#debug ipv6 ospf hello 
  OSPFv3 hello events debugging is on

Becoming OSPFv3 neighbors starts with a hello packet, let’s see what we discover:

R1# OSPFv3: Mismatched hello parameters from FE80::CE01:1BFF:FE29:0
    OSPFv3: Dead R 36 C 40, Hello R 9 C 10
    OSPFv3: Send hello to FF02::5 area 0 on FastEthernet0/0 from FE80::CE

There we go…we see that there is a mismatch in the hello parameters. R1 is configured to send hello packets each 10 seconds and R2 is configured to send them every 9 seconds. The dead timer also has a mismatch. Here’s what the timers look like:

R1#show ipv6 ospf 1 interface fa0/0 | include intervals
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
R2#show ipv6 ospf 1 interface fa0/0 | include intervals
  Timer intervals configured, Hello 9, Dead 36, Wait 36, Retransmit 5

We can verify the timers by using the show ipv6 ospf interface command. Let’s make sure they match:

R2(config)#interface fa0/0
R2(config-if)#ipv6 ospf hello-interval 10

Let’s change the hello timer back to 10 seconds, this also changes the dead timer interval. After a few seconds you’ll see this:

R1# %OSPFv3-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/0 from LOADING to FULL, Loading Done
R2# %OSPFv3-5-ADJCHG: Process 1, Nbr 1.1.1.1 on FastEthernet0/0 from LOADING to FULL, Loading Done

That’s looking good, the routers have become OSPFv3 neighbors:

R1#show ipv6 ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
2.2.2.2           1   FULL/DR         00:00:33    4           FastEthernet0/0
R2#show ipv6 ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
1.1.1.1           1   FULL/BDR        00:00:31    4           FastEthernet0/0

Another problem bites the dust!

Lesson Learned: OSPFv3 for IPv6 has the same requirements to form a neighbor adjacency as OSPFv2 for IPv4. Apply your “IPv4 OSPF” knowledge to solve neighbor adjacency issues.

OSPFv3 over Frame-Relay

Here’s something different for you. We are still working on troubleshooting OSPFv3 neighbor adjacencies but we will use a different topology:

OSPFv3 over Frame Relay

In the scenario above we have a frame-relay setup. There’s a single PVC between R1 and R2. R1 has been configured to use 2001:12::1 and R2 is using 2001:12::2. For some reason the OSPFv3 neighbor adjacency is not working…let’s troubleshoot!

What’s the best place to start troubleshooting a problem like this? There are two options:

  • Start in the middle of the OSI-model and dive into the OSPFv3 configuration right away.
  • Start at the bottom of the OSI-model and check if the frame-relay configuration is properly configured.

Personally I like a structured approach and start at the bottom of the OSI model and work my way up. In this case that means we have to check if the interfaces are up, frame-relay encapsulation has been configured, if the PVC is working, if we have a valid frame-relay map, if we can ping each other and then move on to OSPFv3.

If you start at the bottom you’ll find the problem eventually but it might be a bit more time-consuming sometimes. Just to try something different I’ll start in the middle of the OSI-model this time and we’ll check the OSPFv3 configuration first:

R1#show ipv6 ospf neighbor 

R2#show ipv6 ospf neighbor

I can confirm that there are no neighbor adjacencies. Let’s see if OSPFv3 is active:

R1#show ipv6 protocols 
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPv6 Routing Protocol is "ospf 1"
  Interfaces (Area 0):
    Serial0/0
R2#show ipv6 protocols 
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPv6 Routing Protocol is "ospf 1"
  Interfaces (Area 0):
    Serial0/0

You can see that OSPFv3 has been enabled for the serial 0/0 interfaces. Let’s take a closer look at the OSPFv3 configuration:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now!

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 799 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)
Give Membership a try - it's just $1 ►
581 Sign Ups in the last 30 days
satisfaction-guaranteed

  • 100% Satisfaction Guaranteed!
  • You may cancel your monthly membership at any time.
  • No Questions Asked!

Tags:

Forum Replies

  1. I found something really cool. I dont see it mentioned here so I will bring it up as it may help others especially if they are testing.

    when you use the “Show ipv6 ospf” command it gives some important information.

    1. if your expecting an Area to be shown such as Area 0, Area 1, ect… it will show all the areas that the router sees. This is important as you can check your areas, and if one is missing BAM! Your well on your way to finding your issue and to eliminating other non issues. Obviously this is important tool in the use of this command.

    2. The one I f

    ... Continue reading in our forum

  2. Hey Brian

    Thanks so much for sharing these experiences with us! They can be very helpful, especially for those that are preparing for the same exam as you are!

    Keep at it!

    Laz

  5. Hello Rene,
    I have made up a simple ipv6 lab. I have two routers with link-local addresses and they are up/up. Surprisingly, I can not ping the link-local of the other router, it says the output interface required. Is there a way i should specify this ?

    R1#ping ipv6  FE80::A8BB:CCFF:FE00:2800
Output Interface:
% Interface required

5 more replies! Ask a question or join the discussion by visiting our Community Forum