Solved: Re: ASA BGP - setting metric - Page 2

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.

John N Smith · ‎10-26-2020

Hi All,

Thanks for your interest and help. Apologies, it seems my previous post disappeared.

I think the problem may lie with AWS as they say in their docs one can only rely on med for path selection, but they then advertise with equal metrics.

Here is my config incase this is the issue:

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

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

John N Smith · ‎11-03-2020

Thank you Richard, that is an accurate summary.

Thank you for your suggestion, unfortunately, AWS suggest against using weight or local preference as it interferes with their mechanism for maintenance, which centres around MED: "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)."

This contradicts with what I'm seeing - as both tunnels have an equal MED, there is no 'up tunnel'. I will get in touch with AWS and ask them to clarify.

Thanks,

John.

Richard Burts · ‎11-03-2020

John

Thanks for the additional information. There is a sense of direction in these commands: MED influences what you advertise to them (makes one more attractive than the other) and weight and local preference influence what they advertise to you (makes one more attractive than the other).I am a bit puzzled at the statement about weight or local preference impacting their mechanism for maintenance. But if this is what they say then you certainly should ask them for clarification - and please share that with us when you get it.

HTH

Rick

John N Smith · ‎09-28-2022

Hi Richard,

Over two years later and I'm revisiting this issue. I misunderstood AWS' note about not using Weight or Local Preference - it seems it is only applicable to active / active tunnel setups (where the gateway support asymmetric traffic) (from here: https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNRoutingTypes.html).

Following your advice I've configured MED (metric) and local preference and successfully have two tunnels up, with one preferred both in and out, and no more asymmetric traffic.

A note for people finding this: whereas with MED a lower value indicates preferred path, with local preference a higher value indicates preferred path. See here: https://www.cisco.com/c/en/us/td/docs/security/asa/asa910/configuration/general/asa-910-general-config/route-bgp.html

Thanks very much for your help,

John.

Richard Burts · ‎10-02-2022

John
Thanks for the update. I am glad that my suggestions pointed you to a solution. Thank you for marking this question as solved. This will help other participants in the community to identify discussions which have helpful information. This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.

HTH

Rick