Different amount of AS prepends in same route-map?

[Larry Sullivan]

Can you have a different amount of AS prepends in the same route-map using match statements?  What I'm trying to achieve is having a certain IP used for MIS traffic take our backup VPN at our regional hub instead of saturating the primary MPLS.  The thought is to have the backup VPN advertise less hops to EBGP neighbors than the primary for the MIS traffic generating IP.  See below configs... Will the MIS IP be advertised with 3 prepends and all other traffic 7?  Will this work?  If not, any ideas on how to approach this?  To add more complexity, the purpose is to have the MIS traffic directed to our COLO site instead of direct VPN to the remotes receiving the MIS traffic.  This is being done so that from the COLO facility the traffic will take the primary MPLS circuits at the remotes.  On the way back, the MIS traffic needs to traverse COLO again and back to the regional remotes backup VPN, which is why I need to approach this design from an advertisement standpoint.  Essential I need one IP to prefer the backup with all others the primary.  Thanks.

ip prefix-list MIS seq 5 permit 10.100.4.41/32

route-map Secondary permit 10
 match ip address prefix-list MIS
 set metric 10000
 set local-preference 200
 set ip next-hop 172.21.169.150
 set as-path prepend 65555 65555 65555

route-map Secondary permit 20
 set metric 10000
 set as-path prepend 65555 65555 65555 65555 65555 65555 65555

[Francesco Molino]

Hi

The route-map is correct, however how are you applying that?
Can you share a quick design to be able to help you on all requests?

[Georg Pauwen]

Hello,

to answer the first part of your question: yes, you can set two different as-path prepends in the same route map, in different sequences obviously. The route map you posted probably doesn't work as expected because you are trying to match a prefix list that doesn't exist. Change the access list to a prefix list:

ip access-list MIS seq 5 permit 10.100.4.41/32

--> ip prefix-list MIS seq 5 permit 10.100.4.41/32

route-map Secondary permit 10
match ip address prefix-list MIS
set metric 10000
set local-preference 200
set ip next-hop 172.21.169.150
set as-path prepend 65555 65555 65555

route-map Secondary permit 20
set metric 10000
set as-path prepend 65555 65555 65555 65555 65555 65555 65555

As to the second part of the question: can you post a schematic drawing of what your setup looks like and what you end goal is ?

[Larry Sullivan]

Excuse the mistake with the prefix-list vs access list.  This has not been applied/implemented yet.  I have fixed that.  This route-map would be applied to BGP peering.  VPNs at regional hub is peered to remotes and COLO as backup.  Same with MPLS. 

[Larry Sullivan]

I would apply Primary in and out in BGP configs and apply it at the LAN interface level as well for the PBR?

[Francesco Molino]

Do you have a design to share?

After that we can help, because we usually set as-path outbound to make sure remote bgp prefer a link over another and we use local-pref in to prefer a route from a peer than the other.
In your route-map you combined both and quite sure you don't need it that way. With a sketch and explanation on it we will be able to validate and to give you help on how to achieve what you want to do

[Larry Sullivan · Accepted solution]

Hi Francesco,

I provided a basic drawing in my second post. Let me know if that helps or not. Thanks.

[Francesco Molino]

From regional hub to colo you'll use an acl and a dedicated route-map too build your pbr.

To prefer the return traffic going through colo instead of hub, you can modify as-path or simply use local preference on remote to prefer colo neighbour compared to hub neighbour.

Just a question, are you advertising a /32 today for your host or the complete subnet /24 or whatever?

[Larry Sullivan]

"To prefer the return traffic going through colo instead of hub, you can modify as-path or simply use local preference on remote to prefer colo neighbour compared to hub neighbour."

That won't work, because eBGP neighbor is just the CenturyLink PE IP (the MPLS GW).  And at that point, traffic would just go direct to the MPLS at regional hub as opposed to taking the VPN backup.

"Just a question, are you advertising a /32 today for your host or the complete subnet /24 or whatever?"

Advertising whole /24 subnet as there are other IPs in the subnet that require normal routing. 

[Francesco Molino]

That won't work, because eBGP neighbor is just the CenturyLink PE IP (the MPLS GW). --> i didn't talked about ebgp or ibgp.

You can setup local pref wherever you want as soon as you're using bgp

Can you add bgp peering with each neighbours on your design and also if it's ebgp or ibgp?

[paul driver]

Hello

---

route-map Secondary permit 10
match ip address prefix-list MIS
set metric 10000
set local-preference 200
set ip next-hop 172.21.169.150
set as-path prepend 65555 65555 65555

route-map Secondary permit 20
set metric 10000
set as-path prepend 65555 65555 65555 65555 65555 65555 65555

As to the second part of the question: can you post a schematic drawing of what your setup looks like and what you end goal is ?

---

So you wish:
1) Policy route host 10.100.4.41 via 172.21.169.150

2) Have host 10.100.4.41 advertised in to ebgp peers so it can be seen as the preferred path via the backup link

Now reverting to you route-map you have a lot going on regards manipulating the bgp path attribute especially given that you wish to prepend and use local-preference which as far as I can see from the above won’t work because to prepend with this RM you would want to apply it egress towards MPLS ebgp peers and to LP (which is for IBGP PA manipulation hence the work local-preference) would be applied ingress towards VPN ebgp peers assuming your intention for using LP is for IBGP local preference on ebgp prefixes?

Also you wouldn’t need to have anything stated in the RM stanza 20 either as you only wish for host 10.100.4.41 to be seen as the preferred  path via the vpn link so as stanza 20 is a catch all statement for all other routes  they dont need prepending - However this is providing the route-map for as-path manipulation is applied towards the MPLS peers

Lastly I personally would separate the PBR into a different RM for clarity.

res
Paul

[Larry Sullivan]

Hi Paul,

The route-map would be applied on the backup VPN router.  The intent is to have the iBGP determine the VPN is preferred exit for 10.100.4.41 via local-preference and destination is COLO tunnel IP via PBR.  

I'm also trying to advertise to VPN eBGP peers less hops than what is on the primary MPLS, strictly for 10.100.4.41 for the MIS return traffic, otherwise the return traffic would just take the primary MPLS which has 5 AS prepends as our standard.  The VPN backup usually has 7 prepends per our standard, and that is why there is the second permit 20 statement.  As you put it, it is a catch all for all other subnets.  The permit 20 is intended for normal eBGP configs. 

So, if I separated the route-maps, how would I be able to advertise the 10.100.4.41 as only 3 AS hops via the backup VPN and still have all other subnets/routes advertised as 7 AS hops?

[paul driver]

Hello

---

@Larry Sullivan wrote:

Hi Paul,

The route-map would be applied on the backup VPN router.  The intent is to have the iBGP determine the VPN is preferred exit for 10.100.4.41 via local-preference and destination is COLO tunnel IP via PBR.  

I'm also trying to advertise to VPN eBGP peers less hops than what is on the primary MPLS, strictly for 10.100.4.41 for the MIS return traffic, otherwise the return traffic would just take the primary MPLS which has 5 AS prepends as our standard.  The VPN backup usually has 7 prepends per our standard, and that is why there is the second permit 20 statement.  As you put it, it is a catch all for all other subnets.  The permit 20 is intended for normal eBGP configs. 

So, if I separated the route-maps, how would I be able to advertise the 10.100.4.41 as only 3 AS hops via the backup VPN and still have all other subnets/routes advertised as 7 AS hops?

---

Sounds about right regard you applying Local Preference, as for the As-Path prepending -

Prepend on the mpls path for this host so it will be seen originating with a longer aspath sequence as such the return traffic for this host should then be preferred to come via the alternate vpn link

I would recommend to notify your ISP of your intentions also as they may have rules in place not to allow prepending or the very least to limit it.

res
Paul

[Larry Sullivan]

Lab working

[Francesco Molino · Accepted solution]

Can you share your lab config?

Because it should work:

R1:

ip prefix-list TEST seq 5 permit 10.100.4.41/32

!

route-map TEST permit 10

 match ip address prefix-list TEST

 set as-path prepend 1 1 1

route-map TEST permit 20

 set as-path prepend 1 1 1 1 1 1 1

sh ip bgp neighbors 172.16.255.2 advertised-routes 

BGP table version is 4, local router ID is 1.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 

              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 

              x best-external, a additional-path, c RIB-compressed, 

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path

 *>  1.1.1.1/32       0.0.0.0                  0         32768 ?

 *>  10.100.4.41/32   0.0.0.0                  0         32768 ?

R2:

sh ip bgp

BGP table version is 4, local router ID is 2.2.2.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 

              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 

              x best-external, a additional-path, c RIB-compressed, 

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path

 *>  1.1.1.1/32       172.16.255.1             0             0 1 1 1 1 1 1 1 1 ?

 *>  10.100.4.41/32   172.16.255.1             0             0 1 1 1 1 ?