How to advertise same prefix learnt from different eBGP session to RR

[Eric Guo]

Hi All,

We have two ebgp session from customer CE to our same PE device, and we received same prefix ( with different community attribute), for example below. Since we would like to advertise these 2 same prefixes to  internal Router Reflector at same time for different routing purpose, could someone please help me to figure out how to make it happened?   We are using ASR 9K XR platform, the configuration sample would be great !

on our PE device:

        Network            next-hop      Metric      LocPrf    Wei    Path

*> 10.10.1.0/10    172.16.16.1     0              100         0       100 i

                             172.16.25.1     0              100         0       100 i

thanks very much !

Eric

[Fredrik Lönnman]

Look at using the AddPath feature: http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-2/routing/command/reference/b_routing_cr42crs/b_routing_cr42crs_chapter_01.html#wp2923376411

[xthuijs]

hi eric,

by default a BGP peer would run best path and will only advertise one onward.

you will need to use multipath and or addpath to advertise multiple paths to a route reflector so he can run his best path and advertise one (or more via addpath) out to its route reflector clients.

one thought, instead of having 2 peerings, you could potentially enable a single peering over loopbacks between both peers and use the IGP loadbalancing to balance traffic between that single (bgp) next hop?

regards

xander

[Eric Guo]

thanks guys, 

Above configuration works, but both of entires are showing in RR BGP table, and couldn't become bast path and injected into routing table. ???. 

even for that, these bgp entires couldnot  be advertised forward to other BGP router beside of this RR domain, is it correct? 

Probably this is bad idea for this design approach :-)

any idea? 

thanks, 

Eric 

[xthuijs]

addpath only provides the ability to advetise multiple paths to a neighbor (whether it be an RR or not).

if you want multiple entries (aka ECMP) in the forwarding chain, hence needs to be in the RIB, you also need bgp multipath configured:

under the address family:

 address-family ipv4 unicast
  maximum-paths e(/i)bgp 2

what this does is it will import bgp paths that meet certain criteria.

eibgp: will select both iBGP and eBGP paths for multipathyou may also need:

bgp bestpath as-path multipath-relax
* this can be done if as path lenght is the same.

if not the same we need also:

best path ignore as-path

    (so basically bypass that rule from BGP)

xander

[Eric Guo]

Thanks guys for all your help!

These prefixes have been forwarded to destination properly, this is good.

the next question is, how to force return traffic going into speific next hop? 

for example: in my case here. I would like get return traffic from one BGP peering path through RR back to 172.16.16.1 and other return traffic from other BGP peering path through RR back to 172.16.25.1. 

 as currently, there are 2 bgp enties of 10.10.1.0/10 exsiting on RR right now, the return traffic path is load sharing back to source device now. 

thanks, please let me know if possible.

Eric

[xthuijs]

hi eric, your RR should not be in the forwarding path generally.

but regardless of that, to set a next hop for retrun traffic, you can do a few things:

1) use ABF, access-list based forwarding; check via an ACL to match traffic and as action set a next hop, this forces local routing to take the egress for that next hop. adjacent device will use its regular routing table again or leverage abf if it exists

2) use PBR, to rewrite the actual destination and update the checksum. this is rather powerful so that you dont have to abf on every hop since you are overwriting truly the dest and or source ip.

3) use BGP RPL. When you import the paths from the RR, you can use RPL to match a prefix(set) and set a particular next hop to your liking, so that BGP will install this route with your defined next hop overriden from what the RR advertised.

xander

[Eric Guo]

hi xander, 

Thanks for your information. 

These options above that I tried to test in my lab ( attached diagram of my lab environment) 

1), ABF. I could used it on this physical  interface between RR and internet GW  router and only could force the return traffic for customer B network that is directly connected to RR, and for customer A network that BGP peering far away with RR, I couldn't control that part.

2, PBR, I couldn't find configuration example under cisco XR platform, most of document tell me referral with ABF.

3, BGP RPL, as I understand RPLcorrectly, it  most been used for control routes/prefix by prefix-set and nothing can do with the flow path control . In my environment, could you please share some configuration example that is matching my intention. such as if return traffic of 10.10.1.0/10 back from   AS300 via internet-GW path , we would like take yellow bgp session under 172.16.16.1 interface for customer A, same for 20.10.1.1/10.  And return traffic of 10.10.1.0/10 and 20.10.1.0/10 came back  from Peering through border1 router path, we would like it take back BGP session reach 172.16.25.1 and 172.16.25.9 interface.

thanks, please let me know if possible. 

Eric 

[xthuijs]

hi eric,

correct, ABF is done on a hop by hop bases, but has the advantage that you can match anything an ACL can match on and define a next hop as you like, this however is like ATM NRP's (nailed up relay points) and requires you to define the path end to end. A more automated fashion is to build an LSP, labeled switched path via RSVP-TE or Segment Routing which could be options also.

PBR config is like this, see pictuere here to match on certain traffic and force a destination ip to have it follow that route:

RPL allows you to modify path attributes, such as next hop directly.

so if you like to send particular prefixes in a particular direction where you know what the next hop is, you could leverage RPL to advertise a different next hop, or when the prefix is received to set a next hop so that the border router/bgp speaker can route the packet naturally according to the right nexthop towards the destination.

let me ask this also, are we talking here a sort of academic discussion or is this a true use case, because generally you do NOT want your RR in the forwarding path for both scale, stability and quite some other reasons...

regards

xander

[Eric Guo]

thanks Xander for your all help in patient.

This is a use case for sure.  I know if we could use segregated routing table that would be an ideal resolution for these scenario, but we are limited with budget for huge cost of L3vpn licensing on ASR9K platform, so this is a remedy resolution for making two routing mixed into  global one for now.  Also RR will be float up in the production and only take care for routing. 

I will try both PBR and RPL, and one concern about where is the best of RPL implement point and which direction?

such as

on PE-internet GW outbound BGP session to RR or inbound BGP session to RR?

on RR router outbound  BGP session to PE-internet GW or inbound BGP session to PE-internet GW? 

on PE-ASR9001 outbound BGP session to RR or inbound BGP session to RR?

could I possible know of that ? 

thanks, 

Eric 

[xthuijs]

hi eric,

if you want to do a semi-source based routing option here, you will probably want to look at either PBR or ABF.

if it is only on a per (few) destinations that have to be "redirected" then you can use either of the 3 in which case RPL is the easiest to manage.

I would recommend to centralize such design, meaning that you probably want to send on your route reflector the modified paths to your PE's.

xander

[Eric Guo]

hi Xander, 

Absolutely, you are right. we are going to that path. 

Small question about PBR policy map setup as I couldn't find a command "  set destination-ip  xxx "on my device, is it XR OS version problem or need to install  specific  PIE for it ? my version is 4.3.4.

please let me know if possible. 

thanks, 

Eric 

[xthuijs]

hi eric, ah yeah that PBR set destination func is in 52<EMR>

xander

[Olev Vallaste]

Q. Probably this is bad idea for this design approach :-)

A.>>>

It depends of your design direction  )

Do you want to have additional path as backup in RIB and consequently to have entry in FIB?

Or do you want to implement ECMP with BGP , like Alex described?

May be some scheme exist about your design ?

Is following describing correct?

- ebgp ipv4 in vrf on CE--PE junction

- mp-ibgp vpnv4 on PE--RR junction

Q.even for that, these bgp entires couldnot  be advertised forward to other BGP router beside of this RR domain, is it correct? 

A. >>>

Interesting...

On RR, Is next-hop valid for these prefixes, advertised from PE toward the RR?

One of these prefixes whether advertised from RR toward other BGP routers (other PE?) before configuration above applied?

[Olev Vallaste]

Hi Eric,

May be some config for addpath will helpfull for you:

route-policy ADD-PATH-TO-BGP
   set path-selection all advertise
end-policy

router bgp <AS number>
address-family vpnv4 unicast
  additional-paths receive
  additional-paths send
  additional-paths selection route-policy ADD-PATH-TO-BGP

So on RR your need repeat config above.