Strictly speaking, you loose complete control of inbound routing paths when you announce your prefix to multiple providers because there are independent routing decisions made downstream for return traffic to you. Furthermore, your announcements could even be modified by downstream providers after you send them.
Example
This is one example of what can happen. Suppose you have AS 777, which owns 2.2.0.0/22. You have services that a company with Router A needs to access... Let's also assume that AS 100 doesn't have a good link to you (maybe it's intermittently corrupting traffic due to physical-layer problems you haven't been able to fix). So you think to yourself, "I'll just prepend all my announcements to AS100 with a large number of ASNs so nobody will prefer the AS100 link until I can fix this".
![bgp asymmetric](../../images/3837004970.webp)
The problem is that you only have complete control of your outbound routing decisions. You don't get complete control inbound... so let's suppose Router A's administrator doesn't know your link to AS100 is bad. They are dual-homed to AS200 and AS100, but AS100 offers much cheaper transit, per-Mbps; therefore Router A's engineer takes full routes from AS100 and only uses AS200 as a backup (taking only a default from them).
As the admin of AS 777, you can force traffic to Router A through AS 200, but traffic from Router A to 2.2.0.0/22 would still take AS 100 (because the best route is through AS 100, at Router A).
Possible solutions
Usually asymmetric paths matter because of a load-balancer or firewall that is receiving the traffic. Some possible solutions:
- For services offered in other ASNs, you could source NAT all outbound traffic to an address that is local to a link going to a specific AS (this doesn't work well for service providers though)
- For services offered in your ASN, you could source NAT all inbound traffic to an address that is local to a subnet on your BGP peering router in question (this doesn't work well for service providers though)
- You could set up a DMZ that receives traffic from all the different ASNs and offer a single ingress / egress point for traffic from your upstreams. Under some circumstances, you can even synchronize the state table on the DMZ devices. (this doesn't work well for service providers though)
- If you are willing to use a features like BGP Conditional Advertisement, you can sometimes work around these kind of problems at the cost of not using other carriers for inbound traffic to 2.2.0.0/22.
If you provide more details about the nature of the services and problem, we might be able to offer more specific advice.