BGP neighbour identity and source address

A BGP neighbor is a TCP relationship with a negotiated identity, not just an address in a route list. VyOS needs to know where to send the OPEN, which AS the peer represents, which source to use, and which address family and policy should apply. A correct destination with the wrong source can produce a session that is reachable by ping but not accepted by BGP.

This lesson treats the neighbor stanza as a contract. The operator should be able to read it and answer six questions: who is the peer, what AS does it claim, which local identity is presented, which path must carry TCP 179, what policy is applied, and how the relationship is protected.

The canonical neighbor stanza

The current VyOS 1.5 LTS tree places the local ASN under system-as and the peer under neighbor:

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 description "Transit provider"
commit
save

The equivalent course shorthand is:

set protocols bgp 65000 neighbor 192.0.2.2 remote-as 65100

Use the current form in a live 1.5 LTS change. The rendered FRR configuration and show bgp summary are the final evidence that the neighbor was created under the intended local process.

flowchart LR
  L["Local bgpd<br/>system AS 65000"] -->|TCP 179| R["Remote bgpd<br/>remote AS 65100"]
  R -->|OPEN and KEEPALIVE| L
  L --> P["Source policy<br/>update-source lo"]
  P --> L
  L --> D["Description and monitoring<br/>operator evidence"]
  D --> O["show bgp summary"]

remote-as is not a label

remote-as is a validation constraint. It is not a friendly name or a route preference. FRR compares the configured value with the AS in the peer OPEN. A mismatch normally prevents the session from reaching Established, and a same-AS neighbor is treated as iBGP rather than eBGP.

The current tree also supports remote-as auto and the role-oriented values internal and external in supported releases. An explicit value is usually easier to audit in a production configuration. It makes the intended policy visible to the operator and to automation.

The remote AS must also be the first AS expected in inbound paths for a normal eBGP relationship. A valid session can still receive a malformed or unexpected AS_PATH, which is why enforce-first-as and inbound policy belong in the later design review.

Source address and update-source

FRR normally chooses a local source based on the outgoing interface. That choice is not always the address the peer expects. A loopback is often more stable:

set protocols bgp neighbor 192.0.2.2 update-source lo

The loopback must be present in the routing table, included in the IGP or an approved static path, and accepted by the peer policy. The configuration does not create reachability.

A source-address design is especially important when the peer is multiple hops away, the transit uses VRFs, or the provider applies a neighbor ACL. Check both directions:

show route 192.0.2.2
show route 192.0.2.1
ping -c 3 192.0.2.2 source 192.0.2.1

The first two routes prove the local and return paths. The last test proves the source address is usable from the router. ping is not a BGP test, but a failed source path explains why BGP cannot start.

Interface and unnumbered neighbors

VyOS supports a neighbor identified by an interface for unnumbered BGP. The current form can be especially useful on point-to-point IPv6 links:

set protocols bgp system-as 65000
set protocols bgp neighbor eth1 interface v6only remote-as 65100
set protocols bgp neighbor eth1 interface source-interface eth1
commit
save

The source-interface applies to an interface-defined unnumbered session. It is not a general replacement for update-source on an IPv4 neighbor. Confirm the exact CLI with show configuration and the neighbor summary because capabilities and address-family details matter for unnumbered peering.

A description is operationally valuable:

set protocols bgp neighbor 192.0.2.2 description "ISP-A transit, ticket 1842"

Descriptions do not change routing, but they turn a mysterious IPv4 address into a peer, purpose, ticket, and escalation context. Include the provider, site, role, and contract reference without putting a secret in the description.

Passive mode and who initiates

By default, a configured neighbor can initiate the TCP connection. A passive neighbor only accepts inbound connections:

set protocols bgp neighbor 192.0.2.2 passive

Passive mode is useful when the remote side is authoritative for session initiation, when the local router must not create an outbound TCP flow, or when a provider architecture expects one side to remain a listener. It is not a repair for a missing route or an ACL. If both routers are passive, neither initiates and the session stays down.

How FRR decides what to advertise

The neighbor identity controls update-group behavior and outbound policy inheritance. A peer group can hold shared settings:

set protocols bgp peer-group TRANSIT
set protocols bgp peer-group TRANSIT remote-as 65100
set protocols bgp peer-group TRANSIT description "Transit policy group"
set protocols bgp neighbor 192.0.2.2 peer-group TRANSIT
commit
save

Individual neighbor parameters override a group value when the same parameter is configured directly. That precedence is useful for one provider with a different local role, but it is also a source of surprises. Document both group and per-peer exceptions.

Validation sequence

Read the active stanza first:

show configuration commands | match 'bgp|neighbor'

Then read the runtime relationship:

show bgp summary
show bgp neighbor 192.0.2.2

The summary should show the intended AS, address, and Established state. The detailed neighbor output should show the source address, remote AS, capabilities, address family, timers, and received or advertised prefix counts. If the neighbor is not listed, the local configuration is absent. If it is listed but not Established, move to the state-based checks in the session lifecycle lesson.

Production failure modes

• Remote AS mismatch. The summary may show a neighbor but the session never reaches Established, or the session is incorrectly classified as iBGP.
• Wrong peer address. The configured address belongs to another router, an interface changed, or the provider documentation uses a loopback while the router is listening on a link address.
• Unstable source. A physical source changes during a link event or the source loopback is not reachable through the intended VRF.
• Neighbor policy is too broad. A peer group applies an outbound prefix policy to a member that should have a narrower contract.
• Passive mode on both sides. The operators expect the provider to initiate, but both routers only listen.
• Description is missing. During an outage, the team cannot tell which provider or site owns the address.

Rollback

For a wrong neighbor:

configure
delete protocols bgp neighbor 192.0.2.2
commit
save

For a source problem, first restore the previous update-source or interface source, then verify the route. Do not remove a peer group when only one member is wrong; remove the member assignment or the individual override and preserve the common policy.

Cross-course references

XXIII-VyOS-BGPFund covers AS classification and the iBGP split- horizon rule. XXIV-VyOS-BGPSession continues with timers, authentication, multihop, and state troubleshooting. XXVIII-VyOS-BGPPrefixFilters adds the inbound and outbound policy that makes a neighbor safe, and XXXI-VyOS-BGPTroubleshoot uses the same evidence ladder for a session that remains down. The Linux course covers the source route and TCP socket underneath the neighbor stanza.

Quiz