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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: