Junos OS

This issue is doing my head in.  When initially configured in production, it seemed to work. However, while troubleshooting another issue, this issue crept up.

I'll try to be as detailed, and brief as I can.  In short, the topology is as shown:

This is virtually what's in production, and a not-too-close setup in the lab as well.  The LER is a Cisco ASR 920 and the SRX is a 240.  The lab's SRX is doing triple duty in that it's got two VRFs to take the place of the third party source, and the LSR on the left to originate the default route.  The LER in the lab is a Cisco 1921. 

The idea is to conditionally advertise the public prefixes out of the SRX if the private prefixes are in the routing table as seen from the LER in the MNO VRF.  The SRX in this case does not have a VRF, everything it in its global table.  This piece works separately, so it's a bit of a moot point.

The issue I'm having is between the SRX and the LER within the VRF.  The LER has the routes as advertised by the third party.  The output below is from the lab setup...

      10.0.0.0/8 is variably subnetted, 8 subnets, 6 masks
B        x.x.40.0/21 [20/0] via 172.17.1.33, 2w3d
B        x.x.16.0/21 [20/0] via 172.17.1.33, 2w3d
B        x.x.6.0/23 [20/0] via 172.17.1.33, 2w3d
B        x.x.24.0/25 [20/0] via 172.17.1.33, 2w3d
B        x.x.8.0/21 [20/0] via 172.17.1.33, 2w3d
C        10.249.1.0/29 is directly connected, GigabitEthernet0/1.245
L        10.249.1.1/32 is directly connected, GigabitEthernet0/1.245
B        x.x.48.0/20 [20/0] via 172.17.1.33, 2w3d

...and is advertising them to the SRX...

LER#sho bgp vpnv4 uni vrf MNO nei 10.249.1.6 advertised-routes
 *>  x.x.40.0/21    172.17.1.33                            0 61105 2xxxxx i
 *>  x.x.16.0/21    172.17.1.33                            0 61105 2xxxxx i
 *>  x.x.6.0/23     172.17.1.33                            0 61105 2xxxxx i
 *>  x.x.24.0/25    172.17.1.33                            0 61105 2xxxxx i
 *>  x.x.8.0/21     172.17.1.33                            0 61105 2xxxxx i
 *>  x.x.48.0/20    172.17.1.33                            0 61105 2xxxxx i

However, on the SRX side, it's ignoring them as it sees an AS loop...

onlab@ONWAUKLON02FWL02> show route receive-protocol bgp 10.249.1.1 detail hidden

inet.0: 26 destinations, 28 routes (19 active, 0 holddown, 7 hidden)
  x.x.40.0/21 (1 entry, 0 announced)
     Nexthop: 10.249.1.1
     MED: 0
     Localpref: 100
     AS path: 61105 2xxxxx I (Looped: 61105 2xxxxx)

  x.x.16.0/21 (1 entry, 0 announced)
     Nexthop: 10.249.1.1
     MED: 0
     Localpref: 100
     AS path: 61105 2xxxxx I (Looped: 61105 2xxxxx)

<truncated>

The configuration between the peers in question is as follows:

LER:

router bgp 5xxxx

 address-family ipv4 vrf MNO
  neighbor 10.249.1.6 remote-as 61105
  neighbor 10.249.1.6 local-as 61105
  neighbor 10.249.1.6 update-source GigabitEthernet0/1.245
  neighbor 10.249.1.6 activate
  neighbor 10.249.1.6 next-hop-self
  neighbor 10.249.1.6 prefix-list 3rdParty_PRIVATE out
  neighbor 172.17.1.33 remote-as 2xxxxx
  neighbor 172.17.1.33 local-as 61105
  neighbor 172.17.1.33 activate
  neighbor 172.17.1.33 default-originate
  neighbor 172.17.1.33 prefix-list FROM-3rdParty-PEER in
  neighbor 172.17.1.33 route-map 3rdParty-DEFAULT out

SRX:

set protocols bgp group MNO type internal
set protocols bgp group MNO description MNO_IPV4_PEERS
set protocols bgp group MNO local-address 10.249.1.6
set protocols bgp group MNO advertise-peer-as
set protocols bgp group MNO keep all
set protocols bgp group MNO log-updown
set protocols bgp group MNO family inet unicast
set protocols bgp group MNO peer-as 61105
set protocols bgp group MNO local-as 61105
set protocols bgp group MNO neighbor 10.249.1.1 description LER
set protocols bgp group MNO neighbor 10.249.1.1 export 3rdParty_DEFAULT

 The filters/route maps, etc are nothing more than filtering the routes we're expecting to receive and send.  If there's any additional config required, I'll pop it up. 

Taking a trace of BGP after a clear, I have the following:

Aug 14 15:12:29.345773 BGP RECV         x.x.40.0/21 , x.x.16.0/21 , x.x.6.0/23 , x.x.24.0/25
Aug 14 15:12:29.345879 BGP RECV         x.x.8.0/21 , x.x.48.0/20
Aug 14 15:12:29.346010 bgp_should_merge_as2_and_as4_path():2053 AS4-Peer 10.249.1.1 (Internal AS 61105)(RECV): No merge of as-paths required as the peer is 4 byte as capable
Aug 14 15:12:29.346544 bgp_process_aspath_and_aggr_attr():2502 AS4-Peer 10.249.1.1 (Internal AS 61105)(RECV): bgp_should_merge_as2_and_as4_path() says NO
Aug 14 15:12:29.346639 bgp_process_aspath_and_aggr_attr():2539 AS4-Peer 10.249.1.1 (Internal AS 61105)(RECV): Merged asp: path_len 8, path_seg_len 2, path2_len 0, path2_seg_len 0, path4_len 0, path4_                           seg_len 0, path_attr_len 0, path_aggr_len 0, path4_aggr_len 0, path4_flags 0x0, path_flags 0x0
Aug 14 15:12:29.346733 As loop detected. Rejecting update
Aug 14 15:12:29.346866 bgp_rcv_nlri: Peer 10.249.1.1 (Internal AS 61105)
Aug 14 15:12:29.346961 bgp_rcv_nlri: x.x.40.0/21
Aug 14 15:12:29.347225 ADD      x.x.40.0/21       nhid 0  BGP      pref  metric  <Hidden Int Ext>  as 61105
Aug 14 15:12:29.347618 CHANGE   x.x.40.0/21       nhid 0 gw 10.249.1.1      BGP      pref  metric  <Hidden Int Ext>  as 61105

At this point, I'm at a loss as to where this loop is coming from. I've made one small change in that I've changed the iBGP peering between the SRX and LER to be on AS 5xxxx instead of 61105 and the only change is that 61105 is not mentioned in the AS loop, only 2xxxxx. 

Hello,

Your CSCO LER prepends local-as 61105 as expected

---

@CDRG wrote:

  

...and is advertising them to the SRX...

 

LER#sho bgp vpnv4 uni vrf MNO nei 10.249.1.6 advertised-routes
 *>  x.x.40.0/21    172.17.1.33                            0 61105 2xxxxx i
 *>  x.x.16.0/21    172.17.1.33                            0 61105 2xxxxx i
 *>  x.x.6.0/23     172.17.1.33                            0 61105 2xxxxx i
 *>  x.x.24.0/25    172.17.1.33                            0 61105 2xxxxx i
 *>  x.x.8.0/21     172.17.1.33                            0 61105 2xxxxx i
 *>  x.x.48.0/20    172.17.1.33                            0 61105 2xxxxx i

  

---

See https://learningnetwork.cisco.com/thread/68913 for explanation.

---

@CDRG wrote:

 

At this point, I'm at a loss as to where this loop is coming from.

Loop  comes from CSCO LER who prepends 61105 and keeps 2xxxxx. SRX checks the AS_PATH for any/all ASNs configured on itself including any VRFs and "local-as"  knobs. You did not mention to what ASN Your SRX belongs to - I guess it's 2xxxxx based on Your later statement.

---

@CDRG wrote:

I've made one small change in that I've changed the iBGP peering between the SRX and LER to be on AS 5xxxx instead of 61105 and the only change is that 61105 is not mentioned in the AS loop, only 2xxxxx. 

---

Please share the "show route summary" printout from SRX - I am guessing that SRX also belongs to ASN 2xxxxx.

What You can do is:

1/ keep SRX in AS 2xxxxx, don't use "local-as" on SRX

2/ keep CSCO LER in AS 5xxxx, don't use "local-as" on CSCO

3/ bring regular eBGP peering between CSCO and SRX, add "as-override" to CSCO LER as explained here https://community.cisco.com/t5/network-architecture-documents/understanding-bgp-as-override-feature/ta-p/3111967 (to replace 2xxxxx with 5xxxx )

- and You should be golden.

HTH

Thx

Alex

Thanks. I’d apparently missed cleaning the AS above. 

For the record, 5xxxx is our AS. 2xxxxxx belongs to a third party.  We’d thrown 61105 in the middle for this particular VRF. 

Can’t do #1 as we’re not AS 2xxxxxx.  eBGP will be between the LER in the VRF as shown. Whether we keep that VRF in 61105 or move it to our public AS is something we’d need to discuss. In that respect, I’d gather things would work as expected...but with the private AS in the middle, I guess that’s throwing things out of whack.

So I did a couple of things, but ended up with number two.  It necessitated a few tweaks, but it works as expected. 

Would you mind editing your post to sanitize the 2xxxxx AS please?

Thanks!