- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-07-2025 07:42 AM
Hi cisco community,
Please bare with me but i believe i am missing something in my attempting conversion to ospfv3/w IPV4. Recently, we received a new security device that does not support SHA over OSPFV2. Our network does not have IPV6 present internally, so i began to work on converting to V3 with ipv4.
I understand that i need IPV6 unicast enabled globally on the devices and on the interfaces for the link locals, and my current test config is up and we have Neighbours with IPV4 address on either side. However, there is still "IPV6 family" under the show Neighbours and a loopback i built into the test area to attempt to get into the routing table on the security device fails to do so.
My config:
router ospfv3 1
router-id 10.10.201.1
!
address-family ipv4 unicast
router-id 10.10.201.1
auto-cost reference-bandwidth 100000
exit-address-family
!
address-family ipv6 unicast
exit-address-family
!
!
interface
description OSPF-TEST-INT
no switchport
ip address 10.10.201.1 255.255.255.252
ipv6 enable
ospfv3 encryption ipsec spi xxxx esp aes-cbc 128 7 <key> sha1 7 <key>
ospfv3 hello-interval 1
ospfv3 dead-interval 5
ospfv3 1 ipv6 area 99
ospfv3 1 ipv4 area 99
ospfv3 1 ipv4 area 99 instance 64
However, while we are able to Neighbour with these IPV4 addresses, show neighbours shows ipv6 family. If i remove the ipv6 from the area the connection will drop. I also can't find the route (another 10 rfc address on a loopback) propagating from my cisco to the security device. Am i missing something simple in my config here?
Solved! Go to Solution.
- Labels:
-
Routing Protocols
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-10-2025 09:57 AM
Talked to TAC, they agreeded that the issue is the palo sending the AF bit.
"Third-party devices will not neighbor with devices running the AF feature for the IPv4 AF because they do not set the AF bit. Therefore, those devices will not participate in the IPv4 AF SPF calculations and will not install the IPv4 OSPFv3 routes in the IPv6 RIB."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-07-2025 11:45 AM
Hello,
OSPFv3 uses IPv6 as its transport for IPv4 and IPv6. I'd have to lab it, but can you provide the output of the OSPF neighbor command: show ospf neighbor as you've aid you cna still see IPv4 neighbors?
-David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-07-2025 12:39 PM - edited 03-07-2025 12:42 PM
Hi david,
Correct ospfv3 uses ipv6 link local and ipsec for authentication and encryption.
To be clear, my neighbourship appears to be working fine:
OSPFv3 1 address-family ipv6 (router-id 10.10.201.1)
Neighbor ID Pri State Dead Time Interface ID Interface
10.10.201.2 1 FULL/DR 00:00:04 65 GigabitEthernet4/0/1
It is just reporting ipv6 family even with ipv4 address and does not appear to be exchanging routes. I receive no errors with debug enabled.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-07-2025 07:02 PM
Can you provide the config for both devices please?
You also need to make sure your RIDs are different. I only saw one device configuration.
-David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-08-2025 08:23 AM - edited 03-08-2025 08:26 AM
Hello @jbulloch ,
what you see is normal OSPFv3 with address families or realms relies on the instance ID field to discriminate between instances for ipv6 unicast, instances for IPv4 unicast, instances IDs for ipv6 multicast and instance IDs for ipv4 multicast.
The one byte/ one octet Instance ID that is present in OSPFv3 hellos and other type of packets is partitioned in 4 subsets.
However, you cannot expect to see an IPv4 OSPF neighbor but an IPv6 neighbor with instance ID 64 that should be advertising IPV4 prefixes.
Try to see what happens without any form of authentication to create a baseline and to validate the OSPFv3 configuration.
As noted by @David Ruess OSPF RIDs have to be different in the two nodes in order to accept LSAs from neighbor.
This is true also for OSPFv2
Edit:
about the support of OSPFv3 with address families or realms this is not supported in NX OS it is supported in Cisco IOS XE and Cisco IOS XR.
Hope to help
Giuseppe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-09-2025 11:00 AM
Hi @Giuseppe Larosa ,
Hope you are doing well my friend.
> it is supported in Cisco IOS XE and Cisco IOS XR.
There is still not support for address family ipv4 in ospfv3 in XR.
Regards,
Harold
Harold Ritter, CCIE #4168 (EI, SP)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-10-2025 01:51 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-09-2025 09:04 AM - edited 03-09-2025 09:07 AM
Hi @jbulloch ,
> However, while we are able to Neighbour with these IPV4 addresses, show neighbours shows ipv6 family
You see the address-family ipv6 unicast in the "show ospfv3 neighbor" output because you enabled this address family on the interface. Remove "ospfv3 1 ipv6 area 99" from the interface and address-family ipv6 unicast will disappear from the "show ospfv3 neighbor" output.
> I also can't find the route (another 10 rfc address on a loopback) propagating from my cisco to the security device
You need to enable ospfv3 on the loopback interface so that the loopback ipv4 address is advertised ospfv3.
int lo0
ipv6 enabled
ospfv3 1 ipv4 area 99
Regards,
Harold
Harold Ritter, CCIE #4168 (EI, SP)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-03-2025 10:26 AM - edited 04-03-2025 10:37 AM
Hi everyone,
Thank you for your assistance.
I've done some testing and the issue here appears to be that the security device (a palo alto) is not sending the AF bit when IPV4 is in use. We've done wireshark captures and debug to confirm. This is why we only see neighbour up with ipv6 enabled when we have both "ospfv3 1 ipv4/ipv6 area 99" enabled, and neighbourship shows IPV6. If IPV4 only enabled - and yes ipv6 must be enabled on interface and unicast for the link local - but if ipv6 address familys are removed, it will not neighbour. We can see IPV6 AF shown and it vanishes when IPV4 is used. You can of course, use IPV4 address on interface over the link local but not exchange ipv4/ipv6 routes. This appears to be intended behavior per RFCs.
Debug: OSPFv3-1-IPv4 HELLO Gi4/0/1: Hello from FE80::B60C:25FF:FEE5:41 with AF option bit not set (discarded)
I have built lab out with multiple areas between cisco ios/xe devices (namely 9500, 3560s, and 9400's). These devices are all able to work and propagate routes with only IPV4 address family enabled. With SHA/ESP ipsec enabled as well. Or, even with only IPv6 AF and IPV6 addresses. When i try to make two of the palos talk with ipv4 only, there is no joy either but only with ipv6.
I'am not sure how to resolve this issue. The "firewall guy" here has been through the palo documention and nothing he's found or anything we have tried has been of assistance at this point.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-03-2025 11:22 PM - edited 04-03-2025 11:22 PM
Hello @jbulloch ,
thanks for your feedback. It is clear that the use of address families with OSPFv3 is not so well standardized as it should be. The only option I see for your network scenario is to use OSPFv2 on links to advertise IPv4 prefixes.
You cannot blame Palo Alto implementation of OSPFv3 because also Cisco implements this feature only in IOS XE and not in NXOS or IOS XR as reported here in this thread.
Hope to help
Giuseppe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-04-2025 04:22 AM
Hii giuseppe,
Thanks for the feedback. I will have to find another way so i may end up opening a TAC/Support case with cisco or palo. Reason is the Palo alto only supports MD5 on OSPFV2, SHA and higher on OSPFV3. I cannot use the MD5 per company requirements.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-10-2025 09:57 AM
Talked to TAC, they agreeded that the issue is the palo sending the AF bit.
"Third-party devices will not neighbor with devices running the AF feature for the IPv4 AF because they do not set the AF bit. Therefore, those devices will not participate in the IPv4 AF SPF calculations and will not install the IPv4 OSPFv3 routes in the IPv6 RIB."
