03-05-2020 10:55 AM - edited 03-05-2020 11:00 AM
So, in an effort build a sham link lab setup I have the following setup:
PE1 ----- CE1 running OSPF in VRF VPN_A
PE2 ----- CE2 running OSPF in VRF VPN_A
PE1 is IOS
PE2 is XR
There is a backdoor link from CE1 to CE2.
PE1 and PE2 have a BPG vpnv4 connection to each other. MPLS and LDP running across core. OSPF is redistributing into BPG and vice versa on both PE1 and PE2.
Classic sham link lab.
Before I create the same link, I create loopback 1 (10.2.2.2/32) on PE1 and then use the network command under BGP to get it into the BGP.
I do NOT enable OSPF on the loopback. I need PE2 to see the best path to loopback1 over the MPLS superbackbone NOT over the OSPF connection to CE2.
Now that I think SHOULD happen once I enter the network command is as follows:
But if I look on PE1 I can see the down bit is not being set...
CONFIG:
PE1#sh run | sec router bgp router bgp 100 bgp router-id 2.2.2.2 bgp log-neighbor-changes no bgp default ipv4-unicast neighbor 19.19.19.19 remote-as 100 neighbor 19.19.19.19 update-source Loopback0 ! address-family ipv4 exit-address-family ! address-family vpnv4 neighbor 19.19.19.19 activate neighbor 19.19.19.19 send-community extended exit-address-family ! address-family ipv4 vrf VPN_A network 10.2.2.2 mask 255.255.255.255 redistribute ospf 100 exit-address-family PE1#sh run int lo1 Building configuration... Current configuration : 118 bytes ! interface Loopback1 description sham-link loopback vrf forwarding VPN_A ip address 10.2.2.2 255.255.255.255 end PE1#sh run | sec router ospf 100 router ospf 100 vrf VPN_A router-id 22.22.22.22 area 0 authentication message-digest redistribute bgp 100 subnets PE1#
OUTPUT:
PE1#sh ip ospf 100 database external 10.2.2.2 OSPF Router with ID (22.22.22.22) (Process ID 100) Type-5 AS External Link States LS age: 861 Options: (No TOS-capability, DC, Upward) LS Type: AS External Link Link State ID: 10.2.2.2 (External Network Number ) <<<<<<<<<<<< locally redistributed, ready to be sent to PE1, but down bit is not set Advertising Router: 22.22.22.22 LS Seq Number: 80000002 Checksum: 0x17FD Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 1 Forward Address: 0.0.0.0 External Route Tag: 3489661028 LS age: 2701 Options: (No TOS-capability, DC, Downward) <<<<<<<< THIS IS PE2 (19.19.19.19) redistributing its VPNv4 BGP route back into OSPF and correctly setting down bit. LS Type: AS External Link Link State ID: 10.2.2.2 (External Network Number ) Advertising Router: 119.119.119.119 LS Seq Number: 80000001 Checksum: 0x28E7 Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) MTID: 0 Metric: 1 Forward Address: 0.0.0.0 External Route Tag: 3489661028 PE1#
According to https://tools.ietf.org/html/rfc4576 section 4 "When a type 3, 5, or 7 LSA is sent from a PE to a CE, the DN bit MUST be set.".
Can anyone advise why this isn't happening?
03-06-2020 12:28 AM
There is a nice document which describes loop-prevention techniques when running ospf on ce-pe link.
In this document you can find the following note:
MPLS VPN OSPF PE-CE always includes the loop-prevention mechanism in order to handle issues. In the older Cisco IOS, the Per original IETF draft Type 3 LSAs use the DN Bit in LSA and Type 5 LSAs use a tag. The newer RFC 4576 mandates use of DN Bit for both Type 3 and Type 5 LSAs.
This was committed via Cisco bug ID CSCtw79182.
The PE routers with Cisco IOS images with the fix of this defect will originate Type 5 external LSAs with both DN Bit and a tag as loop-prevention mechanisms. Previous Cisco IOS versions advertised the only tag for this purpose for External Routes.
I hope this helps,
P.
03-06-2020 12:10 PM
Hi Peter,
Thanks for the response.
I think my problem might be related to https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvs74549/?rfs=iqvred.
I'm running IOS-XE version Version 16.6.5, which is covered under this bug. I'll test this in a lab and report back.
For now, if I simply apply a route-map on the redistribution of BGP to OSPF to block the loopbacks, then the sham link works fine.
03-06-2020 01:40 AM
I might be completely missing the point here but... have you configured the actual sham-link between src/dst loopback under OSPF? I think that's what you're missing.
03-06-2020 12:06 PM
Sorry perhaps my discussion is misnamed, my concern is not regarding the actual sham-link itself. Its about the down bit not being set (which is a check I performed before configuring the sham-link). If I use route-maps to filter the loopbacks entering the LSDB it works fine.
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