OSPFv3 and prefix-suppression

[mohammed hashim]

Hi,

on one of my OSPFv3 routers,

when I used prefix-suppresion, I have noticed all loopback interfaces were afeected with this command and their subnet were not advertised to OSPF neighbors:

R4#show ospfv3 ipv4 interface loop0
Loopback0 is up, line protocol is up
Link Local Address FE80::21E:BDFF:FE84:EA00, Interface ID 11
Internet Address 10.255.255.4/32
Area 0, Process ID 1, Instance ID 64, Router ID 10.255.255.100
Network Type POINT_TO_POINT, Cost: 1
Prefix-suppression is enabled

R4:

interface Loopback0
ip address 10.255.255.4 255.255.255.255
ip pim sparse-mode
ipv6 address 2001:10:255:255::4/128
ospfv3 1 ipv6 area 0
ospfv3 1 ipv6 network point-to-point
ospfv3 1 ipv4 area 0
ospfv3 1 ipv4 network point-to-point

R4:

router ospfv3 1
prefix-suppression
bfd all-interfaces
auto-cost reference-bandwidth 1000000
!
address-family ipv4 unicast
passive-interface Loopback0
area 0 authentication key-chain OSPF_KEYS
exit-address-family
!
address-family ipv6 unicast
passive-interface Loopback0
area 0 authentication key-chain OSPF_KEYS
exit-address-family

R4#show ospfv3 ipv4 neighbor

OSPFv3 1 address-family ipv4 (router-id 10.255.255.100)

Neighbor ID Pri State Dead Time Interface ID Interface
10.255.255.5 0 FULL/ - 00:00:34 15 GigabitEthernet1.45
10.255.255.2 0 FULL/ - 00:00:39 15 GigabitEthernet1.24
10.255.255.1 0 FULL/ - 00:00:35 13 GigabitEthernet1.14

my other OSPFv3 routers does not have this issue,

what are the possible causes to this issue?

[Peter Paluch]

Mohammed,

I suspect that this is due to the changed OSPF network type. Loopback interfaces have their own OSPF network type - the LOOPBACK type. Because you have changed the network type, you have in fact made the loopback interface eligible for the prefix suppression. Remember, prefix suppression affects all interfaces except loopbacks, secondary IP addresses, and passive interfaces.

To recover from this, you will not only need to remove the ospfv3 1 { ipv4 | ipv6 } network-type point-to-point - you will also need to kick the OSPF code to reevaluate whether the prefix suppression should be enabled or disabled on the loopback interface, and you can make it by configuring ospfv3 prefix-suppression on that loopback, and removing it a few seconds later. I've tested a 15.5 IOS; it seems that the change in the network type does not cause OSPF to reevaluate the eligibility of the interface for the prefix suppression, so you need to touch that setting manually to have OSPF reevaluate it.

Of course, if you have a reason to have your loopbacks configured for point-to-point OSPF network type, you can also use the ospfv3 prefix-suppression disable command to statically exclude this interface from prefix suppression. However, as you are using /32 and /128 prefix lengths on this interface, configuring it with point-to-point network type is not really necessary.

Best regards,
Peter

[mohammed hashim]

Hi Peter,

thanks for your reply,

actually the testing is a little bit confusing me, I have started one OSPFv3 from scratch and got this result,

1) when I starte OSPFv3 with and using globally prefix-suppression, then everything works as expected, and the loopback addresses are advertised (not suppressed)

2) if on the interface level I use ospfv3 prefix-suppression, then the loopback address get suppressed, if I remove this command using no ospfv3 prefix-suppression, then it get removed from the interface configuration if I issue show run int loop0, but it is kept suppressed in show ospfv3 int loop0

I tried to shut\no shut the loopback interface, as well as restarting the router, nothing helped,

so in this case if I want to suppress the loopback I have to use ospfv3 prefix-suppression disable on the interface level

 BTW, I have not seen any difference when I changed the OSPFv3 netwotk type from P2P to Loopback