Lesson Contents
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:
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:
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:
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.
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.
The one I f
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
Hello team,
There’s a tiny typo at the beginning of the lesson. In the sentense below “OSPFv3 for IPv4” means OSPFv2:
https://cdn-forum.networklessons.com/uploads/default/original/2X/f/f8e01d5c5362e543a22dcd28f53ac75017121822.png
Thanks
Thank you Boris, just fixed this.
Rene
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 ?