Re: Sham Link Lab | downbit not being set correctly

steven.crutchley · ‎03-05-2020

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:

OSPF sees 10.2.2.2/32 in BGP and redistributes it as a type 5 AND SETS THE DOWN BIT.
The LSA is flooded throughout the OSPF domain and PE2 gets it.
It does not redistribute back into BGP because the down bit it set.

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?

filopeter · ‎03-06-2020

There is a nice document which describes loop-prevention techniques when running ospf on ce-pe link.

https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/118800-configure-ospf-00.html

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.

steven.crutchley · ‎03-06-2020

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.

loris.marcellini · ‎03-06-2020

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.

See: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/15-sy/iro-15-sy-book/iro-sham-link.html

steven.crutchley · ‎03-06-2020

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.