Resolving Asymmetric Routing with BGP MED

Answer Correct answer: D — Use BGP MED to influence Site-X return traffic by lowering the metric for the site-specific prefix advertisement to ensure preferred inbound path.

Refer to the exhibit. Two data center sites, X and Y, are connected with a direct backdoor link under these conditions: • Site-specific firewalls are deployed behind the Internet edge routers R1 and R2. • Both sites are advertising the address pool 100.75.10.0/23 toward the Internet. Site-X finds that Internet traffic returning from user PCs comes back on the Site-Y link. Which design resolves the issue? -

Add a static route toward the Internet on Site-X.
Change the Site-Y firewall configuration to replicate the Site-X configuration.
Establish control plane peering between edge routers.
Use BGP MED to influence Site-X return traffic. Correct Answer

Community Votes

44%

38%

19%

44% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The question tests the application of BGP MED (Multi-Exit Discriminator) for inbound traffic engineering, a common trap where candidates might look for prefix changes or peering that aren't feasible.

This scenario involves asymmetric routing caused by identical source prefixes advertised from two sites. The solution uses BGP MED to influence return traffic paths when direct path control is limited.

Candidates often choose C (Control plane peering) because they assume peering allows for policy exchange, but peering itself doesn't solve the routing loop without specific prefix adjustments.

Community Discussion (8 comments)

cisco_guy 👍 6 Selected: C

There's some assumptions and deductions to be made. I would Peer the firewalls together so they both see the same thing from a BGP perspective and from Site-X, I would advertise a longer match, this would solve the asymmetric routing being seen.

sandccie 👍 1 Selected: D

I thought C was the right answer with longer prefix as the solution to resolve the asymmetric routing. However, by doing so the symptom would be shifted to Site-Y. The permanent solution is to have Site-X and Site-Y using unique IP Pools.

i9t6 👍 1

C, longer prefix

JCGO 👍 2

WTF. It's Internet connection. Supposedly to ISP. MED is not transitive attribute. As you know, we are using AS-Path/communities to make that stuff. All answers are literally wrong.

Doobiedoo 👍 3 Selected: D

Use BGP MED to influence Site-X return traffic: By assigning a lower MED (Metric) to the Site-X route, BGP will prefer using the Site-X link for return traffic, thus resolving the issue of traffic going back through Site-Y. Change the IP address scheme of both sites: This is a more permanent solution but involves more significant changes. Assigning different IP address ranges to each site ensures that return traffic is directed to the correct site without relying on BGP MED. Using BGP MED is the most efficient and effective way to correct the traffic routing in this scenario.

Charles2024 👍 1

there is no mention of a firewall in the question

Charles2024 👍 3 Selected: D

they need to split the IP addressing between site x and y.

blurain 👍 3 Selected: B

B might be the right answer. Replicating the firewall policy on both sites is a good practice should the primary site x fail. Also advertising low MED can influence return traffic. My worry is that MED is a non transitive attribute and also there is nothing said about MED config on site y. - no static route needed towards the internet on site x, we know the traffic leave correctly - longer prefix match won't help at it won't be installed in the routing table when comparing it to the shorter prefix - no need change the IP address schema, that might require many other updates: update firewall policies, prefix lists/route maps, wide ips, etc.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

The issue described is asymmetric routing: outbound traffic leaves via Site-X, but return traffic enters via Site-Y because both sites advertise the same /23 prefix. To resolve this without changing IP schemes (which is a design change, not a configuration tweak), we must influence how external peers select the entry point. BGP MED is the standard attribute used for this purpose. By advertising the route with a lower MED from Site-X, edge routers will prefer the Site-X link for returning traffic destined to that prefix.

Why the Other Options Are Wrong

Option A adds a static route, which does not affect how external ISPs route traffic back to the advertised prefix. Option B suggests firewall replication; while good for redundancy, it does not change BGP advertisement attributes and thus doesn't fix the routing preference. Option C suggests control plane peering. While peering can facilitate information exchange, simply peering the routers doesn't inherently change the best path selection unless combined with specific route policies or prefix modifications, which are not mentioned.

Community Comment Notes

Community consensus is split between C and D. Many users argue for C, assuming peering solves the visibility issue, as one user noted "longer prefix" logic often associated with peering benefits. However, others correctly identify that MED is the specific mechanism for influencing inbound traffic flow in this context. Some comments highlight that MED is non-transitive, which is true, but it applies perfectly to the immediate upstream provider relationship implied here.

Official Reference

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13784-25.html

Exam Strategy

When faced with asymmetric routing due to overlapping advertisements, look for BGP attributes like MED or Local Preference first if IP scheme changes are not an option. Remember that MED influences inbound traffic from neighboring ASes.

Frequently Asked Questions

Why isn't peering (C) the correct answer?

Peering alone does not change path selection. Without modifying route attributes or prefixes, routers still see equal cost paths.

Is MED transitive?

No, MED is non-transitive. It is only exchanged between directly connected autonomous systems, making it suitable for local inbound traffic shaping.

Related Analysis

← Back to 400-007 Study Guide