Log in to ask questions, share your expertise, or stay connected to content you value. Don’t have a login? Learn how to become a member.
Pls i need an advice on what could likely be an issue .
3 routers in this scenario , from the diagram i have eBGP and iBGP...R1 advertised 2-prefix to me , which i received on R2 via , here is the problem , i was expecting the prefix to propagate to R3 using the iBGP peer between R2 and R3.pls note R2 and R3 is an MPLSL3VPN setup... I know in this case , BGP rule is not in play now , because these are not prefixes advertised from another IBGP.Kindly advice me on what could be the issue .
Hello olalekan ajayiCan you share From R2:show route receive-protocol bgp <R1 ip neighbor>andshow route advertising-protocol bgp <R3 ip neighbor>Please can you check if you use "next-hop self" attribute when R2 export routes to R3, if not try to add it in the export policy when in iBGP R2 export to R3.Let us know.thank you.
Hello thanks ,See configuration below, please note this not a juniper node actually . i just need some advise on how to go about this .Just for further explanation the eBGP peer between R1 and R2 is in context of OM_CN-vrf and the iBGP peer is also using the context . Like i said it a full mesh BGP , MPLSL3VPN.Below is a script for the R2
configuration on R2=======================
R2#show bgp route neighbor 10.100.100.28 receivedAddress Family: ipv4 unicastLabel Allocation: per-nexthopBGP table version is 288981368, local router ID is 172.16.20.1Status codes: d damped, h history, > best, i internal, + alternateOrigin codes: i - IGP, e - EGP, ? - incompleteRIB download codes: x - not downloaded to RIB (filtered)
Context: OM_CN-vrfVPN RD: 64512:8 Network Next Hop Metric LocPrf Weight Path> 10.10.23.1/32 10.100.100.28 0 100 100 64512 65100 i> 10.10.23.2/32 10.100.100.28 0 100 100 64512 65100 i
configuration of bgp peergroup on R2=======================================
router bgp 64512 router-id 172.16.20.1 address-family ipv4 vpn nexthop triggered delay 0 holdtime 1 backoff 0! peer-group MP-BGP internal advertisement-interval 0 update-source loopback-local address-family ipv4 vpn
neighbor 172.16.10.11 internal peer-group MP-BGP description R3
By design iBGP does not propagate any routes but the local ones. There are two options:All iBGP peers are full mesh peering with each other (default expected behavior)A route reflector is added and all iBGP clients peer to the route reflector to get the routes (middle router in your case)eBGP would have the behavior you are expecting by default.
Hi @olalekan ajayi ,R2 should ideally have advertised the eBGP route received from R1 to R3, as an iBGP peer advertises an eBGP route to another iBGP peer. R3 would not further advertise it to any other iBGP peer, as for R3 it would be an iBGP route on R3. Can you kindly share the outputs of the below from R2- show route receive-protocol bgp <R1 IP> extensive- show route advertising-protocol bgp <R3 IP> extensive- show bgp summaryfrom R3-show bgp summary-show route receive-protocol bgp <R2-IP> extensiveThe output of "show protocols" from the R2 and R3 routers will also be helpful.
Okay let me set this straight node I m dealing with here is not a juniper product, it an Ericsson node .@sheetanshu thanks for the break down again, this were all the principle of bgp which I believe should have worked properly. But unfortunately I'm not seeing prefixes on the R3.Let me explain further the setupSo R2 and R3 are peer using the loopback in an mplsl3vpn. I have different context (vrf) on those box so I won't be able to share advertised route in vrf ,because the peer are in global routing table .But yes, I m learning route advertised on R3 in R2 in same vrf .But this particular case, the ebgp learnt prefixes on R2 is not propagating on R3
Hi,While I have not worked on an Ericsson node, the following are general checks: -- Even with MPLS L3 VPN and vrf configurations, R2 will advertise the vpnv4 routes to R3. We can still look at the advertised vpnv4 prefixes from R2 to R3 and verify the route-target/next-hop and other relevant route attributes to ensure these values are expected.- In the vrf configuration, do we have correct route-target values/import-export policies configured?- Does the route advertised by R2 have a valid next-hop for it to be accepted on R3 (next-hop-self)?Regards
Thanks to everyone, all suggestions make sense So I found the problem and fixed it . Here is it , on the ebgp configuration VRF I was using ASN 64512 . This was the same ASN for the iBGP I'm using in the global bgp .For some reason in the vrf the R3 was dropping the prefixes it was receiving in the context .So I thought about changing the ASN number which I was using to peer on the ebgp and all issue was resolved.
Good catch, to close the loop the definition of iBGP is peers that have the same ASN. As a result the stopping of redistribution of prefixes beyond the direct peer would correctly apply in that case absent a route reflector configuration.
Hi @spuluka - This shouldn't actually be a problem, as in the given topology R2 and R3 are direct iBGP peers. So even if the eBGP peering in the vrf with R1 and the mp-bgp peering with R3 use the same ASN, R2 should advertise the routes to R3 (being the adjacent iBGP peer). I simulated the scenario with suggested here with vMXs and it works perfectly fine with single ASN on R2.Regards