A cooperative wants its BGP export policy toward a transit provider to advertise only the static routes representing its subscriber DSL pools, and nothing learned via OSPF or direct interface routes. Which from match condition in the export policy term achieves this source-based selection?
Select an answer to reveal the explanation.
Short Explanation
To pick out only the subscriber-pool routes and leave OSPF and directly connected routes alone, the export term should match from protocol static, since that's literally how those subscriber routes got into the table in the first place. Matching on OSPF would grab the wrong source entirely, and the other two options aren't even the right kind of condition for this job. Source protocol is the cleanest way to select exactly one origin.
Full Explanation
A from protocol static condition matches routes based on the protocol that originally installed them into the routing table, which in this scenario correctly isolates the subscriber DSL pool routes, since those were configured as static routes, while excluding anything sourced from OSPF or from directly connected interfaces. This kind of source-based selection is a routine building block for a cooperative's export policy, because it lets an engineer redistribute exactly one category of internally originated route to a transit provider without also leaking the entire internal OSPF topology or every connected subnet. The OSPF distractor is wrong because it selects precisely the opposite source, the internally learned OSPF routes the scenario explicitly wants excluded, rather than the subscriber statics that should be advertised. The to protocol bgp distractor misunderstands direction: to conditions describe where a route is headed, such as toward a specific protocol or neighbor on export, and while the policy is indeed being applied on a BGP export, a to protocol bgp condition does not filter by the route's origin, so it would not exclude the OSPF or direct routes at all. The interface-based distractor is the wrong match dimension entirely, since matching by inbound interface says nothing about which protocol originally installed the route, and static routes are not tied to a receiving interface the way learned routes are. A caveat is that a real policy here would typically pair from protocol static with a route-filter to further limit which static prefixes qualify, avoiding an overly broad match. A concrete check is show route protocol static, compared against show route advertising-protocol bgp <transit-neighbor>, to confirm only the intended statics went out.