11-19-2018 01:37 PM - edited 11-19-2018 01:38 PM
Hello All,
I have a question related to NSSA and the P-bit on NX-OS.
I am trying to lab a scenario on GNS3 with NX-OSv where I have routes learned via BGP on N7K-1 from R1. These are then redistributed into OSPF for propagation throughout area 0 (topology diagram attached).
The problem I am having is that when the type 7 LSA's are generated by N7K-1, it is neglecting to set the P-bit, thereby disallowing N7K-2 to perform type 7 to 5 translation. I do not seem to have this issue on traditional IOS as from my understanding it will set the P-bit automatically, however NX-OS seems to require some sort of manual intervention to get it working. Snooping around on Cisco's documentation, I see that there is a command to tell the switch to set the P-bit (area 0.0.0.25 nssa translate type7 always) however this does not seem to work. I feel like this should be simple but I can't figure out what is wrong. Any ideas would be greatly appreciated.
P.S. Show commands also attached. Let me know if anything further is required.
Solved! Go to Solution.
11-20-2018 02:16 AM
Hello All,
Just to provide an update, I found the problem last night after my question had been erroneously marked as spam right after posting it (????).
Whilst I was configuring N7K-1 I remember I had accidentally configured E2/3 with the interface config that should have been applied to E2/3 on N7K-3 (specifically ip router ospf 10 area 0). Noticing this at the time, I entered the good ol' default interface e2/3 command which I expected would remove the associated config I had previously applied to the interface.
Turns out that this command does not work as expected in NX-OSv and it did not actually delete anything at all. Due to this config, OSPF was basically not only seeing itself as an ASBR but also saw itself as an ABR. According to the rules of OSPF, when a NSSA router performs both of these roles simultaneously, it will *NOT* set the P-bit in the generated type-7 LSAs. Once I manually went into E2/3 on N7K-1 and deleted the commands the LSAs were then re-generated which consequently led to N7K-2 (ABR) translating the LSAs into type 5 externals.
Those are a good few hours I will not be able to get back lol.
11-20-2018 02:16 AM
Hello All,
Just to provide an update, I found the problem last night after my question had been erroneously marked as spam right after posting it (????).
Whilst I was configuring N7K-1 I remember I had accidentally configured E2/3 with the interface config that should have been applied to E2/3 on N7K-3 (specifically ip router ospf 10 area 0). Noticing this at the time, I entered the good ol' default interface e2/3 command which I expected would remove the associated config I had previously applied to the interface.
Turns out that this command does not work as expected in NX-OSv and it did not actually delete anything at all. Due to this config, OSPF was basically not only seeing itself as an ASBR but also saw itself as an ABR. According to the rules of OSPF, when a NSSA router performs both of these roles simultaneously, it will *NOT* set the P-bit in the generated type-7 LSAs. Once I manually went into E2/3 on N7K-1 and deleted the commands the LSAs were then re-generated which consequently led to N7K-2 (ABR) translating the LSAs into type 5 externals.
Those are a good few hours I will not be able to get back lol.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide