eBGP multihop and peer groups

A directly connected eBGP session normally sends packets with TTL 1. That default is a safety feature: the peer is expected to be reachable through the local interface and the next-hop checks are meaningful. A production design sometimes needs a routed peer, a loopback pair, or two sites that are not adjacent. In that case, the operator must change the TTL deliberately and prove the complete path.

Multihop is not a magic route. It is a transport contract consisting of a destination, a source, a routed return path, a hop limit, an authentication choice, and a policy boundary. Peer groups help manage common settings, while allowas-in and as-override address AS_PATH reuse in carefully constrained topologies. Both are easier to misuse than to configure.

Why eBGP uses TTL 1 by default

The default TTL expresses that the peer is expected to be one IP hop away from the configured source. If the chosen source is a loopback several hops from the peer, the destination can be reachable in the routing table and still be unreachable to BGP because the packet expires before it arrives.

The default also interacts with FRR’s connected-route check. The check prevents a neighbor address that is not directly connected from being accepted under the single-hop default. The operator can either make the design genuinely single-hop, choose a direct peer address, or configure a documented multihop path.

flowchart LR
  S["Source loopback<br/>192.0.2.1"] --> R1["R1 transit"]
  R1 --> R2["R2 transit"]
  R2 --> P["Peer 192.0.2.2"]
  S -->|TCP port 179| P
  P -->|return path| S
  N["Default eBGP TTL 1"] -. "expires at R1" .-> X["No session"]
  M["ebgp-multihop with validated path"] --> P

A high TTL does not fix a route that is not in the table. It also does not authorize a peer to advertise every prefix. The path must be stable and the policy must still restrict the address family and prefixes.

Configure a routed eBGP session

A typical loopback-to-loopback design uses a stable source and a bounded hop count:

configure
set protocols bgp system-as 65000
set protocols bgp parameters router-id 192.0.2.1
set protocols bgp neighbor 192.0.2.2 remote-as 65100
set protocols bgp neighbor 192.0.2.2 update-source 192.0.2.1
set protocols bgp neighbor 192.0.2.2 ebgp-multihop 5
commit
save

The update-source value is an address or interface, depending on the VyOS tree and the address family. The source must be reachable through the routing table in the same routing context as the neighbor. The return path must be present at the peer and allowed by its local ACL or firewall.

Set the hop count to the actual path design, not to the maximum value to make a session appear. A value of five is meaningful only when the source, destination, and failure domain are documented. A peer that is actually two hops away with TTL five may be reachable today but can become three hops after an IGP change and still work until another event changes the path. Use a stable routed topology and monitor it.

GTSM is an alternative constraint

The current VyOS tree also supports:

set protocols bgp neighbor 192.0.2.2 ttl-security hops 1

GTSM sends with TTL 255 and accepts inbound packets only from a configured hop distance. It is mutually exclusive with ebgp-multihop in the documented tree. GTSM protects against packets that arrive from farther away than the configured relationship; it is not a replacement for MD5 or TCP-AO and it is not an arbitrary workaround for a wrong source address.

Choose one transport model:

• direct peer and TTL 1;
• routed multihop with an explicit TTL and source;
• GTSM with a hop limit that matches a direct or carefully designed source relationship.

Do not configure all three options and hope that one wins. The configuration commit or runtime validation should reject an incompatible design.

Peer groups scale configuration, not understanding

A peer group applies common settings to a set of neighbors. A small provider group might look like this:

configure
set protocols bgp peer-group TRANSIT
set protocols bgp peer-group TRANSIT remote-as 65100
set protocols bgp peer-group TRANSIT update-source 192.0.2.1
set protocols bgp peer-group TRANSIT ebgp-multihop 5
set protocols bgp peer-group TRANSIT advertisement-interval 5
set protocols bgp neighbor 192.0.2.2 peer-group TRANSIT
set protocols bgp neighbor 192.0.2.3 peer-group TRANSIT
commit
save

Peer groups can reduce repeated configuration and allow FRR to process some update work more efficiently. They can also hide a member-specific difference. A parameter configured on an individual neighbor takes precedence over the same group parameter. Record every exception and keep the group name descriptive enough to identify the policy class.

A peer group is not a route reflector, and assigning a member does not make it iBGP. Each member still has its own neighbor identity, address, remote AS, and state. The group only supplies shared configuration and update-group behavior.

allowas-in and the loop rule

BGP normally rejects an incoming path when it contains the local ASN. That loop check prevents a site from accepting a route that appears to return to the same AS. Some dual-homing and route-server designs reuse an ASN across sites, so they need a controlled exception.

VyOS 1.5 LTS exposes:

configure
set protocols bgp neighbor 192.0.2.2 address-family ipv4-unicast allowas-in number 1
commit
save

The value limits how many occurrences of the local ASN may be accepted on the address family. It is not a recommendation to accept an unbounded number of occurrences. allowas-in is a loop-prevention override; it must be paired with prefix filters, prefix limits, a description, and a topology explanation.

as-override addresses a different problem: a provider may need to replace a customer ASN when advertising a customer route back toward that customer. The current tree exposes:

set protocols bgp neighbor 192.0.2.2 address-family ipv4-unicast as-override
commit
save

Do not use as-override to hide a topology mistake. It changes a policy attribute at a defined boundary and must be coordinated with the customer and the provider.

Validation

A multihop design needs four proofs:

show route 192.0.2.1
show route 192.0.2.2
show bgp summary
show bgp neighbor 192.0.2.2

The source and destination routes must point through the intended routing instance. The summary must show the expected remote AS and Established. The detailed neighbor output must show the negotiated address family, source, authentication, and update activity.

Then test traffic and the return path:

ping -c 3 192.0.2.2 source 192.0.2.1
tcpdump -ni any host 192.0.2.2 and tcp port 179

A ping can pass through an interface source even when the loopback source used by BGP is not accepted by the peer. The packet capture must show the actual BGP source and return packets.

How it fails

• The eBGP TTL is left at 1 while the neighbor is a loopback behind an IGP, so the session stays in Active.
• The source address is reachable from the router but filtered by the peer, so the return TCP packets never complete.
• A peer group applies one hop count to members with different paths, creating a session that works until an interface or metric changes.
• GTSM and multihop are configured together, producing a commit or validation failure.
• allowas-in is set to an unbounded or excessive value, allowing a looped path to survive long enough to create intermittent outages.
• A provider changes its path from two to four hops, but the static TTL value is not reviewed against the new design.

Rollback

Restore the previous transport design before changing AS_PATH exceptions:

configure
delete protocols bgp neighbor 192.0.2.2 ebgp-multihop
commit
save

If the source is the problem, remove the source override and restore the former peer address. For a bad allowas-in or as-override setting, remove the address-family override and verify the neighbor view. If a peer group was changed, restore the previous group and keep the member assignment only if the individual member still belongs to the policy.

Cross-course references

XXIII-VyOS-BGPFund covers eBGP TTL, iBGP split horizon, and AS_PATH. XXIV-VyOS-BGPSession covers neighbor, timer, and authentication details. XXX-VyOS-BGPRouteReflectors explains a different iBGP scaling mechanism, while XXXI-VyOS-BGPTroubleshoot handles route and path validation. LIII-VyOS-Security broadens control-plane protection, and the Linux course covers the routed source and TCP path beneath the BGP session.

Quiz