Dell OS10 BGP Configuration: CLI Steps and Verification

OS10 keeps its routing configuration close to the FRR syntax that many engineers already know, which makes BGP on a Dell PowerSwitch quick to learn - provided you respect OS10's transaction-based configuration model and the address-family activation step that quietly decides whether routes are exchanged at all. This guide configures eBGP and iBGP neighbours on a PowerSwitch, uses templates to keep large peer sets manageable, injects networks, and finishes with the verification commands that prove the session and the RIB are healthy.

The audience for this walkthrough is an engineer who knows BGP and knows Cisco. Everything that is genuinely different on OS10 is a small number of sharp edges: the configuration is a transaction that must be committed, a neighbour is a sub-mode rather than a one-line command, and a peer can be perfectly established while carrying no routes at all. Get those three right and the rest is familiar.

Before BGP: the prerequisites people skip

OS10# configure terminal
OS10(config)# interface loopback0
OS10(config-if-loopback0)# ip address 10.0.0.1/32
OS10(config-if-loopback0)# exit
OS10(config)# interface ethernet1/1/1
OS10(config-if)# no switchport
OS10(config-if)# ip address 10.12.1.1/30
OS10(config-if)# exit
OS10(config)# ip route 0.0.0.0/0 10.12.1.2
OS10(config)# commit

A BGP router ID must be the IP of a configured L3 interface - a loopback is the correct choice. Confirm the interface is in routed mode (no switchport); a BGP neighbour over a switchport will never establish, and the error message gives no hint about the real cause.

Two further prerequisites are worth stating explicitly because they cause the same class of confusing failure:

• Reachability is checked with the FIB, not with a ping from the management plane. If the peer address is not in the routing table with a directly connected or recursive route, the session stays in Active or Idle. Make sure the prefix covering the peer address resolves before you debug BGP itself.
• The router ID must exist before BGP starts. If you configure router-id pointing at a loopback that has not been created, OS10 silently derives a router ID from some other interface, and every iBGP session that relies on loopback reachability behaves as though the topology were different from what you drew.

Understanding the OS10 configuration model before you type

OS10 is a Linux-based network operating system with a transactional configuration layer in front of its routing stack. The practical consequences show up in day-to-day operations:

• Everything is a candidate configuration until you commit. You can build an entire BGP configuration, inspect it, and then throw it away with discard - nothing reaches the forwarding hardware or the routing process until commit. This is the single biggest behavioural difference from IOS, where every line takes effect as you press Enter.
• A configuration can be syntactically valid and semantically dead. Because OS10 accepts changes into a candidate and validates at commit, mistakes such as a neighbour defined outside any address family are accepted happily and only revealed by looking at the peer's prefix count. Verification is not optional on this platform.
• Running versus startup configuration are distinct. show running-configuration is what the switch is doing now; the startup configuration is what it will do after a reload. Committing without saving is a well-known way to lose a maintenance window's work.

eBGP and iBGP neighbours

OS10(config)# router bgp 65001
OS10(config-router-bgp-65001)# router-id 10.0.0.1
OS10(config-router-bgp-65001)# log-neighbor-changes

! external peer
OS10(config-router-bgp-65001)# neighbor 10.12.1.2
OS10(config-router-neighbor)# remote-as 65002
OS10(config-router-neighbor)# description eBGP-to-ISP
OS10(config-router-neighbor)# no shutdown
OS10(config-router-neighbor)# exit

! internal peer, update-source pinned to the loopback
OS10(config-router-bgp-65001)# neighbor 10.0.0.2
OS10(config-router-neighbor)# remote-as 65001
OS10(config-router-neighbor)# update-source loopback0
OS10(config-router-neighbor)# no shutdown
OS10(config-router-neighbor)# exit

! address family - this is what actually enables exchange
OS10(config-router-bgp-65001)# address-family ipv4 unicast
OS10(config-router-af)# neighbor 10.12.1.2 activate
OS10(config-router-af)# neighbor 10.0.0.2 activate
OS10(config-router-af)# network 10.0.0.0/24
OS10(config-router-af)# exit
OS10(config-router-bgp-65001)# exit
OS10(config)# commit

The activate statement under address-family ipv4 unicast is the step that catches everyone coming from IOS: configure the neighbour without activating it in the address family and the session comes up while carrying zero routes. In OS10, neighbor ip-address enters a per-neighbour sub-mode, so you configure one peer at a time unless you use templates.

Note what the example deliberately does not do: it does not enable next-hop-self on the iBGP peer, and it does not enable additional address families. Both omissions are correct for a first session and both are common causes of "the session is up but the routing table looks wrong". If the iBGP peer is a route reflector or a router that is not in the forwarding path of the advertised prefixes, you need neighbor 10.0.0.2 next-hop-self under the address family - without it, the receiving router tries to resolve a next hop it cannot reach and the routes stay in the BGP table but never enter the FIB.

Why the activate step exists, and how to spot an inactive peer

The two-stage model - name the neighbour, then activate it in an address family - is inherited from the multi-address-family design of modern routing stacks, where the same peer can carry IPv4 unicast, IPv6 unicast and Layer 2 VPN families independently. It is more verbose than IOS, but it is also more precise: the policy attached to a peer is scoped per address family, which is why route-map, send-community and maximum-paths in the examples above appear inside address-family ipv4 unicast rather than at the neighbour level.

The diagnostic signature of a missing activation is unmistakable once you know it: show ip bgp summary shows the peer as established, but the State/PfxRcd column shows a zero or a dash instead of a prefix count, and the neighbour detail output shows no negotiated capability for the family you expected. Connectivity, timers and authentication are all fine - the routes simply were never negotiated.

Peer templates for larger deployments

OS10(config-router-bgp-65001)# template ISP-PEERS
OS10(config-router-template)# description "ISP facing peers"
OS10(config-router-template)# remote-as 65002
OS10(config-router-template)# timers 10 30
OS10(config-router-template)# ebgp-multihop 2
OS10(config-router-template)# address-family ipv4 unicast
OS10(config-router-af)# send-community
OS10(config-router-af)# route-map RM-IN in
OS10(config-router-af)# route-map RM-OUT out
OS10(config-router-af)# exit
OS10(config-router-template)# exit
OS10(config-router-bgp-65001)# neighbor 10.12.1.6 inherit template ISP-PEERS
OS10(config-router-bgp-65001)# exit
OS10(config)# commit

Templates keep policy consistent across many peers and make a config audit realistic: one route map referenced in one place instead of twenty. Combine with a route map that sets local preference and communities for inbound traffic engineering.

The timing values in the template are worth a second look. timers 10 30 means a 10-second keepalive and a 30-second hold time, which is the aggressive profile used when fast failure detection matters and the peer agrees. If the peer is a service provider running the default 60/180, a mismatch will not break the session - BGP negotiates hold time down to the lower value - but it does mean your side will declare the peer dead after 30 seconds, which is the intended behaviour and should be an explicit decision rather than a copy-paste.

Scaling iBGP: route reflectors on OS10

Once the iBGP mesh exceeds a handful of routers, the full mesh becomes unmanageable and route reflection is the standard answer. On OS10 the configuration is FRR-shaped: the reflector is a normal iBGP neighbour, and the clients are marked inside the address family.

OS10(config-router-bgp-65001)# bgp cluster-id 10.0.0.1
OS10(config-router-bgp-65001)# neighbor 10.0.0.10
OS10(config-router-neighbor)# remote-as 65001
OS10(config-router-neighbor)# update-source loopback0
OS10(config-router-neighbor)# no shutdown
OS10(config-router-neighbor)# exit
OS10(config-router-bgp-65001)# address-family ipv4 unicast
OS10(config-router-af)# neighbor 10.0.0.10 activate
OS10(config-router-af)# neighbor 10.0.0.10 route-reflector-client
OS10(config-router-af)# exit
OS10(config)# commit

Two operational points that come up in every OS10 route-reflector deployment. First, the cluster ID must be unique across the AS and is normally set to the reflector's loopback - two reflectors sharing a cluster ID create a loop that is very hard to debug from the routing table alone. Second, redundant reflectors should be configured with consistent policy, because a client receiving the same prefix from two reflectors with different inbound route maps will simply prefer the better path and hide the inconsistency until one reflector fails.

Protecting the table: prefix limits and inbound policy

An eBGP session without a prefix limit is an availability risk. A peer that leaks the full internet table into a session you expected to carry a handful of prefixes will, in the best case, exhaust the routing table and, in the worst case, remap your traffic. Every external peer should have a maximum prefix count and a policy that discards anything outside the expected range.

! inbound filter: accept only the prefixes this peer should send
ip prefix-list PEER-203-0-113 seq 10 permit 203.0.113.0/24
!
route-map RM-IN permit 10
 match ip address prefix-list PEER-203-0-113
 set local-preference 200
 set community 65002:100
route-map RM-IN deny 20
!
OS10(config-router-af)# neighbor 10.12.1.2 maximum-prefix 500
OS10(config-router-af)# neighbor 10.12.1.2 route-map RM-IN in
OS10(config-router-af)# neighbor 10.12.1.2 send-community
OS10(config-router-af)# exit
OS10(config)# commit

The explicit deny 20 term is not decoration. A route map with only permit statements behaves differently from one with an implicit deny in some platforms and in some address families; writing the deny makes the intent auditable, and it means a peer that starts advertising a default route or a bogus more-specific is dropped before it reaches best-path selection.

Fast failure detection with BFD

BGP's default hold time is measured in tens of seconds, which is far too slow for a data centre fabric where the physical layer can detect a failure in milliseconds. OS10 supports BFD and, as with the rest of the routing configuration, it is a two-part setup: enable BFD on the interface, then reference it from the BGP neighbour.

OS10(config)# interface ethernet1/1/1
OS10(config-if)# bfd enable
OS10(config-if)# bfd interval 100 min_rx 100 multiplier 3 no shutdown
OS10(config-if)# exit
OS10(config)# router bgp 65001
OS10(config-router-bgp-65001)# neighbor 10.12.1.2
OS10(config-router-neighbor)# bfd
OS10(config-router-neighbor)# exit
OS10(config)# commit

OS10# show bfd neighbors
OS10# show bfd neighbors detail

BFD is negotiation-based: if the peer does not support it, the session is unaffected and you simply keep the slower BGP timers. That makes it safe to enable broadly, and the show bfd neighbors output tells you immediately which sessions actually got a BFD session established - the difference between "configured" and "working" on this platform is exactly the kind of thing that OS10's candidate config makes easy to confuse.

Verification

OS10# show ip bgp summary
OS10# show ip bgp neighbors 10.12.1.2
OS10# show ip bgp neighbors 10.12.1.2 advertised-routes
OS10# show ip bgp neighbors 10.12.1.2 received-routes
OS10# show ip bgp
OS10# show ip bgp 10.0.0.0/24
OS10# show running-configuration bgp
OS10# show ip route bgp
OS10# clear ip bgp *                     ! reset all sessions (be careful)
OS10# clear ip bgp 10.12.1.2 soft in      ! re-apply inbound policy only

In show ip bgp summary a healthy peer shows established in the State/Pfx column along with a prefix count. If the session is established but the prefix count is zero, the address-family activation or a route map is the problem - not connectivity. Remember that OS10 configuration is transactional: uncommitted changes exist only in the candidate configuration, so show running-configuration is the source of truth and discard throws away a session's worth of edits.

The difference between advertised-routes and received-routes is where most BGP disputes get settled. On the sending side you can prove exactly which prefixes you are offering; on the receiving side, whether the peer is offering what it claims. Both commands are cheap and both should be part of the change record for any peer turn-up. Note that received-routes requires an inbound policy to be applied on the neighbour - without one, the command reports that no inbound soft reconfiguration has been enabled, which is itself a useful reminder that the peer has no filter.

Troubleshooting: symptom to cause

Operational notes

Keep log-neighbor-changes enabled and ship the logs off-box; pair BGP with BFD for sub-second failure detection where the peer supports it; and validate the whole change in a containerlab or lab switch first. Related reading: Dell OS10 OSPF configuration, OS10 transaction-based configuration mode, BGP best path selection and route reflectors and cluster-id.

原文链接：https://www.dell.com/support/manuals/en-cr/dell-emc-smartfabric-os10/smartfabric-os-user-guide-10-5-0/enable-bgp