Solved: Re: ASA BGP - setting metric

John N Smith · ‎10-15-2020

I have an ASA configured using VTI to have two tunnels (to AWS). This is causing an issue with asymmetric traffic.

This Cisco support doc details using a route map to set the metric on the BGP routes, to ensure symetric traffic e.g.

route-map toAWS2 permit 10
 set metric 200
 exit

router bgp 65000
 address-family ipv4 unicast
  neighbor 169.254.12.85 route-map toAWS2 out

However,

show bgp

shows all external routes have a metric of 100. The route map seems to be ignored.

Is there a mistake in the support document? Do route maps require a `match` attribute?

Any help would be much appreciated,

John.

Richard Burts · ‎10-27-2020

I am not clear on the current state of this discussion. So let me address what I believe have been the focuses of this discussion. You are using a route map to set metric (MED) for prefixes that you advertise to them, so that they will have a primary path and a backup path for how they send traffic to you. I think we can assume that this is working correctly. It does appear that the prefixes that they advertise to you are sent with equal attributes. If you wish to have the same type of primary path/backup path for traffic that you send to them it should work if you use a route map inbound and in that route map assign either weight or local preference. (if you have a single router communicating with them then either weight or local preference would be effective, but if you had more than 1 router talking to them then you would need to use local preference).

HTH

Rick

View solution in original post

Seb Rupik · ‎10-15-2020

Hi there,

The

show bgp

command will show you the BGP routing table containing the received prefixes and metrics. Since the AWS VPN are sending you prefixes with the same metric implies that the two VPN are equally preferred and the AWS TGW has probably been configured with 'VPN ECMP Support'. This option only appears when creating the TGW.

Carefully recreate the TGW looking for this option and re-attach the VPNs to the TGW. You should then hopefully see a higher mteric being recieved via one of your VPNs. It is this VPN peer that you apply the route-map with the higher metric to ensure symetric routing.

https://aws.amazon.com/premiumsupport/knowledge-center/transit-gateway-ecmp-multiple-tunnels/

cheers,

Seb.

MHM Cisco World · ‎10-15-2020

Your config is right not issue,
if there is no match then by default it will match all prefix.

John N Smith · ‎10-23-2020

Hi Seb,

I really thought this was the problem but after recreating the TGW and ensuring "VPN ECMP support" was disabled

show bgp

still shows both routes with the same metric. I can't see any other ECMP options on the AWS side of things.

Could it be that "VPN ECMP support" (and disabling it) is only applicable for multiple VPN connections, not multiple tunnels within the same connection?

I'm stumped!

Thanks,

John.

MHM Cisco World · ‎10-23-2020

Can I see all config of BGP?
I suspect that you config the metric between two iBGP where metric not work between iBGP peer it only work between eBGP.
check this point

John N Smith · ‎10-23-2020

Hi MHM Cisco World,

I think you may be right, all routes in the BGP table are shown with an 'i', indicating they are IGP, is that correct?

All metric, weight, and path are equal.

MHM Cisco World · ‎10-26-2020

Asa AWS,

in

 show ip bgp

do you see the as of aws in path or not?

if not then you config ibgp not ebgp, and metric not work with ibgp.

so please just change any as to make it differ

John N Smith · ‎10-23-2020

I've now tried configuring AWS with 2 VPN connections (4 tunnels), and the metric is still 100 for all routes.

Could the options "Default association route table" and "Default propagation route table" have anything to do with it? They are both currently disabled.

MHM Cisco World · ‎10-24-2020

can I see

show bgp

in ASA?

Georg Pauwen · ‎10-24-2020

Hello,

post the running configuration of your ASA, otherwise it keeps being back and forth guesswork. What if you configure one of the other options available, e.g.:

router bgp 65000

--> bgp bestpath compare-routerid

Richard Burts · ‎10-24-2020

I think we are making this more complicated than it needs to be and there is a simple explanation. The route map is applied out so it is setting the metric on what you advertise to your peer. Show up bgp shows what your peer has advertised to you. That is why you don’t see the changed metric.

HTH

Rick

paul driver · ‎10-26-2020

Hello
However

show bgp

shows all external routes have a metric of 100. The route map seems to be ignored.
The receiving rtr might not have ignored it, bgp may well have chosen a older path other than the one with the med you've set and advertised .

If all is equal upto med attribute then the bgp compares routes for med like this:

newest  v 2nd newest
winner v 3rd newset
winner v oldest 
path selected

Lastly med is compared from routes originating from the same AS, otherwise it is ignored unless you tell bgp rtrs to always compare med from differing ASN's

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

John N Smith · ‎10-26-2020

Hi MHM Cisco World, Georg Pauwen, Richard Burts, paul driver,

Thanks very much for your interest and your time.

This is the current router config:

router bgp 65000
 bgp log-neighbor-changes
 address-family ipv4 unicast
  neighbor 169.254.83.249 remote-as 64512
  neighbor 169.254.83.249 activate
  neighbor 169.254.83.249 route-map route-map-aws-1 out
  neighbor 169.254.159.253 remote-as 64512
  neighbor 169.254.159.253 activate
  neighbor 169.254.159.253 route-map route-map-aws-2 out
  network 172.28.0.0
  network 172.29.0.0
  network 172.30.0.0
  network 172.31.0.0
  no auto-summary
  no synchronization
 exit-address-family

route-map route-map-aws-1 permit 10
 set metric 100

!
route-map route-map-aws-2 permit 10
 set metric 200

!

And show BGP:

*> 10.0.0.0/20      169.254.159.253    100             0  64512 i
*>                  169.254.83.249     100             0  64512 i
*> 10.0.32.0/20     169.254.159.253    100             0  64512 i
*>                  169.254.83.249     100             0  64512 i
*> 10.0.64.0/20     169.254.159.253    100             0  64512 i
*>                  169.254.83.249     100             0  64512 i
*> 10.0.80.0/20     169.254.159.253    100             0  64512 i
*>                  169.254.83.249     100             0  64512 i
*> 10.0.96.0/20     169.254.159.253    100             0  64512 i
*>                  169.254.83.249     100             0  64512 i
*> 10.1.0.0/16      169.254.159.253    100             0  64512 i
*>                  169.254.83.249     100             0  64512 i
*> 10.2.0.0/20      169.254.159.253    100             0  64512 i
*>                  169.254.83.249     100             0  64512 i
*> 10.3.0.0/20      169.254.159.253    100             0  64512 i
*>                  169.254.83.249     100             0  64512 i
*> 10.3.0.0/16      169.254.159.253    100             0  64512 i
*>                  169.254.83.249     100             0  64512 i
*> 172.28.0.0       0.0.0.0              0         32768  i
*> 172.29.0.0       0.0.0.0              0         32768  i
*> 172.30.0.0       0.0.0.0              0         32768  i
*> 172.31.0.0       0.0.0.0              0         32768  i

I now understand that

show bgp

is showing what AWS has advertised to me. Can I influence these routes using config on my local device, for instance, the

bgp bestpath compare-routerid

command, or is this down to AWS?

Paul, is it possible to see when a path has been chosen using 'age' over med? Would that be apparent in the

show bgp

output, above?

Some info from AWS. It sounds to me like AWS should be advertising its routes with different metrics, and everything else should be configured equally, is that correct?

This would be in line with the AWS config doc from Cisco, however, does not match what I'm seeing.

From AWS:

...prioritizes routes as follows, from most preferred to least preferred:

- For matching prefixes where each Site-to-Site VPN connection uses BGP, the AS PATH is compared and the prefix with the shortest AS PATH is preferred.

- When the AS PATHs are the same length and if the first AS in the AS_SEQUENCE is the same across multiple paths, multi-exit discriminators (MEDs) are compared. The path with the lowest MED value is preferred.

Note: We do not recommend using AS PATH prepending, to ensure that both tunnels have equal AS PATH. This helps to ensure that the multi-exit discriminator (MED) value that we set on a tunnel during VPN tunnel endpoint updates is used to determine tunnel priority.

On a Site-to-Site VPN connection, AWS selects one of the two redundant tunnels as the primary egress path.

For Site-to-Site VPN connections that use BGP, the primary tunnel can be identified by the multi-exit discriminator (MED) value. We recommend advertising more specific BGP routes to influence routing decisions.

Note: To ensure that the up tunnel with the lower MED is preferred, ensure that your customer gateway device uses the same Weight and Local Preference values for both tunnels (Weight and Local Preference have higher priority than MED).

Thanks again for the help, all,

John

paul driver · ‎10-26-2020

Hello

yes you can and it doesn’t need to be med there are more preferred attributes that you could use such as weight or local preference- As this looks like a single rtr in its own ASN then weight attribute would be a good option

You can set a higher weight value on a whole neighbour or based just on specific received routes per neighbour using acl /prefix-list incorporated with a route-map assigned ingress if you desire.

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

John N Smith · ‎10-26-2020

Thank you Paul.

I've read up on AWS recommendations and it looks like using anything other than MED would prevent the redundant tunnel from operating as intended.

From AWS:

Some info from AWS. It sounds to me like AWS should be advertising its routes with different metrics, and everything else should be configured equally, is that correct?

This would be in line with the AWS config doc from Cisco, however, does not match what I'm seeing.

From AWS:

...prioritizes routes as follows, from most preferred to least preferred:

- For matching prefixes where each Site-to-Site VPN connection uses BGP, the AS PATH is compared and the prefix with the shortest AS PATH is preferred.

- When the AS PATHs are the same length and if the first AS in the AS_SEQUENCE is the same across multiple paths, multi-exit discriminators (MEDs) are compared. The path with the lowest MED value is preferred.

Note: We do not recommend using AS PATH prepending, to ensure that both tunnels have equal AS PATH. This helps to ensure that the multi-exit discriminator (MED) value that we set on a tunnel during VPN tunnel endpoint updates is used to determine tunnel priority.

On a Site-to-Site VPN connection, AWS selects one of the two redundant tunnels as the primary egress path.

For Site-to-Site VPN connections that use BGP, the primary tunnel can be identified by the multi-exit discriminator (MED) value. We recommend advertising more specific BGP routes to influence routing decisions.

Note: To ensure that the up tunnel with the lower MED is preferred, ensure that your customer gateway device uses the same Weight and Local Preference values for both tunnels (Weight and Local Preference have higher priority than MED).