ArubaOS-CX BGP Configuration and Verification - 夜莺博客

ArubaOS-CX BGP Configuration and Verification

ArubaOS-CX is a campus and aggregation platform, but its BGP implementation is a full one: address families per neighbour, route policies, multipath, graceful restart and EVPN. The part that trips people up is the same part that trips people up on every modern CLI — neighbours are not active until they are activated inside an address family, and the address family is where the policy goes. This article covers a working configuration and the verification sequence that proves each layer.

The minimal working configuration

switch(config)# router bgp 65001
switch(config-bgp)# bgp router-id 10.0.0.1
switch(config-bgp)# bgp log-neighbor-changes
switch(config-bgp)# maximum-paths 4
!
switch(config-bgp)# neighbor 10.0.0.2 remote-as 65002
switch(config-bgp)# neighbor 10.0.0.2 description transit-primary
!
switch(config-bgp)# address-family ipv4 unicast
switch(config-bgp-ipv4-uc)# neighbor 10.0.0.2 activate
switch(config-bgp-ipv4-uc)# neighbor 10.0.0.2 maximum-routes 20000
switch(config-bgp-ipv4-uc)# neighbor 10.0.0.2 route-map RM-IN in
switch(config-bgp-ipv4-uc)# neighbor 10.0.0.2 route-map RM-OUT out
switch(config-bgp-ipv4-uc)# exit-address-family
!
switch(config-bgp)# exit
switch(config)# write memory

Two structural points: the activate command is mandatory (configuring a neighbour without activating it leaves the session idle), and route-maps are attached inside the address family, not at the router level. Both mirror IOS XE conventions closely enough that the mental model transfers, but the prompts and exit commands do not.

Policies, prefixes and communities

switch(config)# ip prefix-list PL-DEFAULT seq 10 permit 0.0.0.0/0
switch(config)# ip prefix-list PL-BOGONS seq 10 deny 10.0.0.0/8 le 32
!
switch(config)# route-map RM-IN permit 10
switch(config-route-map-RM-IN-10)# match ip address prefix-list PL-BOGONS
switch(config-route-map-RM-IN-10)# set local-preference 90
! note: a route-map with entries that only match will not deny anything -
! add an explicit deny entry if the intent is to filter
!
switch(config)# route-map RM-IN deny 20

A route-map entry with no permit/deny keyword defaults to permit, and a matching entry with only set clauses passes the route through with modified attributes. If your goal is filtering, the deny entry has to be explicit — the same trap exists on every platform, and it is why inbound filters should always be verified with counters rather than by reading the config.

Common session options

switch(config-bgp)# neighbor 10.0.0.2 update-source loopback 0
switch(config-bgp)# neighbor 10.0.0.2 ebgp-multihop 5
switch(config-bgp)# neighbor 10.0.0.2 password MySecret
switch(config-bgp)# neighbor 10.0.0.2 timers 10 30
switch(config-bgp)# bgp graceful-restart restart-time 120
switch(config-bgp)# neighbor PEERS peer-group
switch(config-bgp-ipv4-uc)# neighbor PEERS activate

Loopback peering plus ebgp-multihop is the standard design for an aggregation switch with two uplinks, because it survives a single link failure without re-establishing the session. Note that update-source and ebgp-multihop are configured at router level while activation and policy live in the address family.

Verification, layer by layer

show bgp all summary                 ! sessions, states, prefix counts
show bgp ipv4 unicast summary
show bgp neighbor 10.0.0.2           ! capabilities, timers, message counters
show bgp ipv4 unicast                ! the BGP table as received and filtered
show bgp ipv4 unicast 203.0.113.0/24 ! best path and why
show bgp ipv4 unicast neighbors 10.0.0.2 advertised-routes
show ip route bgp                    ! what actually got installed
show bgp l2vpn evpn summary          ! if EVPN is in use

The diagnostics order that saves the most time: session state first (summary), then received versus advertised (neighbor ... advertised-routes), then the routing table. A prefix present in show bgp but absent from show ip route is a next-hop or route-selection problem, not a peering problem — the same failure mode described in BGP next-hop handling.

Symptoms and causes

  • Neighbour in Idle/Active — no TCP reachability, wrong remote-as, or a password mismatch. Check show bgp neighbor counters: a rising "Connections dropped" with no Established time is a session-level issue.
  • Session up, no routes — the neighbour was never activated in the address family, or an inbound prefix-list is denying everything.
  • Routes received but not best — attribute comparison, usually local preference or AS path length. show bgp ipv4 unicast <prefix> prints the reason.
  • Only one of several equal paths used — maximum-paths not configured, or the paths differ in an attribute that must match (for example MED, unless bgp bestpath med behaviour is adjusted).

Related on this site: ArubaOS-CX VRRP active gateway for the first-hop redundancy that usually accompanies a BGP edge design, and the BGP best-path algorithm for interpreting the selection output line by line.

原文链接:https://arubanetworking.hpe.com/techdocs/AOS-CX/10.13/PDF/ip_route_6300-6400-8100-83xx-9300-10000.pdf