Redistributing connected routes — physical interface routes, when to include, when to exclude

redistribute connected carries the router’s connected routes — the subnets assigned to its interfaces — into the BGP table. It differs from a network statement in one important way: a connected route exists only while its interface is up, so the advertisement follows the interface. That is the property that makes it the right tool, and the property that makes an unfiltered one dangerous.

On VyOS 1.5 LTS the production use cases are narrow:

• Customer point-to-point links — a /30 between the router and the customer. Redistributing it makes the link reachable, and withdraws it when the link drops.
• DMZ or service subnets — the router hosts a service on a /28 that other networks need to reach.
• Loopbacks in a BGP-only underlay — a data-centre fabric with no IGP, where each router’s loopback has to reach the other end somehow, and BGP is the only protocol running.

The production anti-pattern is an unfiltered redistribute connected, which advertises every interface subnet the router has: the transit link to the upstream, the management interface, the peering subnet, and whatever gets configured next week.

Connected versus a network statement

Two mechanisms advertise a local prefix into BGP, and the difference between them is what happens when reality changes:

• network enumerates a prefix explicitly. It is advertised as long as a matching route exists in the routing table, and it does not care which interface produced that route. set protocols bgp address-family ipv4-unicast network 10.10.0.0/16 advertises the aggregate whether it came from a static route, an IGP, or an interface.
• redistribute connected advertises interface subnets and follows their state. An interface that goes down takes its prefix out of BGP with it.

For a customer /30, the redistribution is right: the link state is exactly the signal you want BGP to carry. For a summary you always want advertised, the network statement is right, because it says what you mean and does not change when somebody renumbers an interface.

Both statements live under the address family on VyOS 1.5, which is the placement that moved in 1.4 and the first thing a 1.3-era runbook gets wrong here.

flowchart TB
  LO["lo\n10.0.0.1/32"]
  ETH0["eth0\n192.168.1.1/24 (customer)"]
  ETH1["eth1\n10.10.10.1/30 (transit to upstream)"]
  ETH2["eth2\n172.16.0.1/24 (management)"]
  PEER["eth3\n198.51.100.1/29 (eBGP peering)"]
  R["Connected routes in the RIB"]
  RM["route-map CONNECTED-TO-BGP"]
  BGPLoc["BGP table"]
  X["Not redistributed"]

  LO --> R
  ETH0 --> R
  ETH1 --> R
  ETH2 --> R
  PEER --> R
  R --> RM
  RM -->|"customer 192.168.1.0/24"| BGPLoc
  RM -->|"transit, management, peering, loopback"| X

The configuration

configure

set policy prefix-list CONNECTED-TO-BGP rule 10 action 'permit'
set policy prefix-list CONNECTED-TO-BGP rule 10 description 'customer LAN'
set policy prefix-list CONNECTED-TO-BGP rule 10 prefix '192.168.1.0/24'

set policy prefix-list CONNECTED-TO-BGP rule 20 action 'permit'
set policy prefix-list CONNECTED-TO-BGP rule 20 description 'customer point-to-point'
set policy prefix-list CONNECTED-TO-BGP rule 20 prefix '203.0.113.4/30'

set policy route-map CONNECTED-TO-BGP rule 10 action 'permit'
set policy route-map CONNECTED-TO-BGP rule 10 match ip address prefix-list 'CONNECTED-TO-BGP'
set policy route-map CONNECTED-TO-BGP rule 10 set metric '100'
set policy route-map CONNECTED-TO-BGP rule 10 set community add '64512:500'

set protocols bgp system-as 64512
set protocols bgp address-family ipv4-unicast redistribute connected route-map 'CONNECTED-TO-BGP'

commit
save

The prefix-list enumerates what may pass. The route-map matches it and stamps a metric and a community so that downstream policy has something to filter on. The redistribution statement names the route-map.

The connected-source semantics

A connected route is live only while its interface is up. Take the interface down and the route leaves the RIB; the redistribution follows and BGP withdraws the prefix.

That is useful. A customer /30 that goes down is withdrawn without anybody doing anything, and downstream peers converge on an alternative if one exists.

It is also the mechanism behind the leak. redistribute connected is a standing instruction, not a snapshot. The moment any new interface is configured — a management VLAN, a temporary link for a migration, a new peering — its subnet becomes a connected route and is caught by the standing instruction. If the route-map does not exclude it, it is advertised, and nobody typed a command to make that happen.

Which interfaces belong in BGP

The defensive idiom is one line long: enumerate every subnet that should be advertised, and let the implicit deny handle the rest.

The loopback question

The table above splits on whether an IGP is running, and that split is worth its own section because it is where the strongest habits collide.

In a network with OSPF or IS-IS, router loopbacks belong to the IGP, not to BGP. The iBGP mesh peers with update-source set to the loopback, and every BGP next-hop has to resolve against something — which is the IGP. Redistributing a loopback into iBGP on top of that adds nothing, and in the wrong order it does not work at all:

A BGP-only underlay is the genuine exception. In a fabric with no IGP, redistribute connected filtered to the loopbacks is how each switch’s loopback becomes reachable — and it works there because the sessions are eBGP over the point-to-point links, so the next-hop is the neighbour’s link address rather than the prefix being advertised. The circularity above does not arise.

Operational commands

show ip route connected
show interfaces

show ip bgp
show ip bgp 192.168.1.0/24

show bgp ipv4 neighbors 203.0.113.5 advertised-routes

vtysh -c 'show route-map CONNECTED-TO-BGP'
vtysh -c 'show ip prefix-list CONNECTED-TO-BGP 192.168.1.0/24'

show bgp ipv4 neighbors <peer> advertised-routes is the validation that matters. Everything else tells you what the router intends; this tells you what the peer is being given. Run it after every redistribution change and read the list, not its length.

vtysh -c 'show ip prefix-list <name> <prefix>' answers “would this prefix pass” directly, which is faster than reasoning about rule order. And show route-map carries a hit count per rule: a rule with zero hits and a policy that is not working is a match problem, not a set problem.

Failure modes

Unfiltered redistribution leaks management and peering subnets

redistribute connected was committed without a route-map. Every interface subnet is in BGP, including 172.16.0.0/24 (management) and the peering subnet.

Diagnostic:

• show bgp ipv4 neighbors <peer> advertised-routes lists subnets nobody intended to sell.
• The upstream’s received-routes shows the same, which is how you usually find out.

Fix: add the prefix-list and route-map, attach the route-map to the redistribution, and ask the upstream to confirm the withdrawal propagated. Withdrawing a leaked prefix is fast; getting it out of other people’s route caches and filters is not, so treat this as an incident rather than a tidy-up.

The interface is up and the prefix is not in BGP

Work down the chain rather than guessing:

• show ip route connected — is the connected route in the RIB at all? An interface with an address but no carrier has no connected route.
• vtysh -c 'show ip prefix-list CONNECTED-TO-BGP 192.168.1.0/24' — does the prefix-list permit it?
• Check ge and le on the prefix-list rule. A rule with prefix 192.168.0.0/16 and no ge/le matches only the exact /16, not the /24 inside it. This is the single most common reason a prefix-list “does not work”.
• vtysh -c 'show route-map CONNECTED-TO-BGP' — is rule 10 taking hits?

The route is in the BGP table and not in the FIB

The next-hop is unresolvable. On an iBGP-received route this is usually the loopback circularity above, or a border router that should be setting next-hop-self and is not.

Diagnostic: show ip bgp 192.168.1.0/24 names the next-hop, and show ip route for that next-hop address says whether the router can reach it. If the answer is no, the fix is in the IGP or in next-hop-self, not in the redistribution.

Rollback

• compare before commit, and confirm the redistribution and its route-map are both in the diff. Committing the redistribution without the route-map — because the route-map was going to be a second commit — is a leak with your name on it.
• commit-confirm 5 for the change, since redistribution changes what the upstream receives immediately.
• To remove the redistribution: delete protocols bgp address-family ipv4-unicast redistribute connected and commit.
• To remove only the filter and keep the redistribution: delete protocols bgp address-family ipv4-unicast redistribute connected route-map. Understand what this does before typing it — it does not disable anything, it makes the redistribution unfiltered.
• rollback N exists but currently requires a reboot to take effect. For a leak you want the targeted delete and a commit, not a reboot.

Production discipline

Cross-course references

• II-VyOS-RoutingFund (vyos-ii-03-connected-routes) covers the connected route source.
• XXXIV-VyOS-Redistribution (vyos-xxxiv-05-redist-kernel) covers the kernel route source, which carries the same filtering discipline.
• XXX-VyOS-BGPRouteReflectors covers the iBGP mesh whose loopback reachability this lesson argues belongs in the IGP.

Quiz