Your edge is accepting routes it shouldn't
A BGP peer is sending you a prefix you never agreed to carry. The session is fine. You just need to accept what you want and drop the rest.
Scenario
You run R1 (AS 65001) and you peer with a partner network, R2 (AS 65002). The agreement is simple:
you accept only their 10.0.2.0/24. But R2 is also advertising 10.0.50.0/24, and right now your
router is installing it: you have no inbound filter, so you take whatever they send.
The session is healthy. This is about policy: accept what you agreed to, drop the rest.
Topology
- R1: AS
65001, link IP10.0.12.1/30 - R2: AS
65002, link IP10.0.12.2/30, advertising10.0.2.0/24(allowed) and10.0.50.0/24(not)
Your job
Put an inbound filter on R1 so it accepts 10.0.2.0/24 from R2 and does not install 10.0.50.0/24.
Don't touch R2.
What "done" looks like
R1's table has 10.0.2.0/24 via BGP and no 10.0.50.0/24.
Teaches: a working session carries whatever the peer sends unless you filter it. A prefix-list (or route-map) applied inbound is how you enforce what you actually agreed to accept.
What gets checked
Your solution is verified against each of these:
- The eBGP session between R1 and R2 is Established
- R1 has 10.0.2.0/24 in its table, learned via BGP
- R1 does NOT install 10.0.50.0/24 (it is filtered inbound)
Solve it in the browser lab
No setup, no install. Open a live lab: configure each device in the editor or its Cisco IOS terminal, run show/ping/traceroute (or test from the hosts), and watch the network react. The in-house engine grades your fix instantly and issues your proof the moment every check passes.
Open the lab →Prefer your own lab?
- Build the fix locally. New to the tooling? See setting up your lab.
- Push your topology file, device configs, and any playbooks to a public repo (GitHub or GitLab).
- Submit the repo link. We review it by hand, confirm it works, and issue your proof page.