BGP Session Establishment and Neighbor Configuration
BGP Session Establishment and Neighbor Configuration
This domain covers bringing a session up and keeping it up: SR OS group and neighbor configuration, eBGP versus iBGP parameters, loopback peering, timers, authentication and the knobs that must match on both sides.
Configuration building blocks
In SR OS a BGP session is always configured under a group, and the group supplies defaults. The chain is configure router autonomous-system 65000, then under configure router bgp create group "ebgp" type external peer-as 65001 and add neighbor 192.0.2.1. iBGP groups use type internal and inherit the local AS as peer-as. Export and import policies control what you send and accept; with no export policy in place, SR OS is deliberately conservative about what it originates.
Peering over loopbacks in eBGP needs three things together: multihop <ttl>, local-address <loopback>, and a route to the peer's loopback in the base routing table. Without multihop the packet leaves with TTL 1 and dies.
Timers: default hold-time is 90 seconds with a 30-second keepalive, and keepalive must not exceed one third of hold-time. connect-retry governs retry spacing, and min-route-advertisement throttles eBGP updates (default 30 s).
Protection options: authentication-key (TCP MD5) or key chains (TCP-AO), ttl-security (GTSM, requires TTL 255), passive to stop outbound attempts from a hub, and prefix-limit to cap learned prefixes.
Worked example
AS 65001 peers with AS 65002 over loopbacks 10.0.0.1 and 10.0.1.1. Configure neighbor 10.0.1.1 multihop 2 local-address 10.0.0.1 peer-as 65002. If the session stays in Active, verify each side has a route to the other loopback and that the local-address matches what the peer expects - not the physical interface address.
Traps
Wrong peer-as causing a NOTIFICATION loop; omitting multihop; MD5 or TCP-AO configured on one side only; and confusing local-address (TCP source) with next-hop-self (what you advertise).