Nokia BGP Fundamentals for Services common mistakes
Nokia BGP Fundamentals for Services · Understand the traps and how to avoid them.
Treating the BGP best-path algorithm as a single ordered list without knowing where the locally-originated route, the weight, and the local preference steps sit relative to each other, and then picking a winner that the real tie-break order would not select.
Candidates memorize a mnemonic but never anchor it to the actual order: weight first, then local preference, then locally originated, then AS path length, origin, MED, eBGP over iBGP, and finally the IGP metric to the next hop. Because weight and local preference are Cisco-specific concepts and locally-originated routes are often forgotten, the tie-break chain is misremembered.
What to do instead
Rebuild the list from first principles and rehearse it as a decision tree: ask at each step whether the comparison is even reached. Practice with a table of five candidate routes for one prefix and document, step by step, which routes are eliminated and why. Explicitly note that MED is only compared between paths from the same neighbouring AS by default, and that the IGP-metric step is only reached after eBGP-over-iBGP.
Assuming a session that reaches Established will stay up, and failing to distinguish an Idle/Active flap caused by a transport or reachability problem from a flap caused by a hold-timer expiry or a notification.
Candidates learn the FSM states in isolation but never map symptoms to states. A session stuck in Active is usually a TCP connect or return-path problem, while a session that reaches Established and then drops points to timers, MTU, authentication, or a capability mismatch. Without that mapping, every failure looks like 'BGP is broken'.
What to do instead
Learn the diagnostic signature of each state: Idle (no route to peer or administratively down), Connect/Active (TCP SYN not completing, wrong neighbour address, ACL, or no return route), OpenSent/OpenConfirm (capability, AS number, or authentication mismatch), Established then drop (hold timer, KEEPALIVE loss, MTU black hole, or notification). Practice reading the last notification code and subcode before touching configuration.
Configuring a route reflector or confederation without checking that the cluster ID, the client/non-client relationship, and the loop-prevention attributes are consistent across the design, then expecting routes to propagate that never will.
Candidates treat route reflection as a simple 'add neighbour as client' command. They miss that a route received from a client is reflected to clients and non-clients, a route from a non-client goes only to clients, and that ORIGINATOR_ID and CLUSTER_LIST provide the loop prevention. A duplicate cluster ID or a mis-scoped client silently blackholes routes.
What to do instead
Draw the reflection rules as a matrix (from client / from non-client, to client / to non-client) and verify each against the configuration. Confirm every reflector in a cluster shares the same cluster ID, that clients peer only with reflectors, and that you can explain why ORIGINATOR_ID prevents a route returning to its originator. Test with a single prefix and trace it hop by hop.
Applying an inbound or outbound route filter or policy and expecting it to change the local best path, when the filter only suppresses advertisement or acceptance of the prefix.
Candidates conflate 'filtering a route' with 'depreferring a route'. A deny in an inbound filter drops the route entirely, which may cause a fallback to a less preferred path or a blackhole, whereas a route-map that sets local preference keeps the route but deprioritises it. The distinction between implicit deny at the end of a filter and a permit-all default is frequently missed.
What to do instead
For every policy, state the intended effect in one sentence: drop, accept, or modify an attribute. Always check the implicit deny and add an explicit permit if needed. Use a route-map with a set clause for preference changes and a filter for suppression. Verify with the received and advertised route tables on both sides after each change.
Forgetting that an iBGP-learned route is not re-advertised to another iBGP peer, and then designing a full-mesh or reflector topology that relies on a router passing a route along.
The iBGP split-horizon rule is stated early and then forgotten under design pressure. Candidates draw a chain of iBGP routers and assume the route propagates like an IGP route. The result is a design that needs a full mesh or a reflector but does not have one.
What to do instead
State the rule explicitly before any iBGP design: a route learned from an iBGP peer is only advertised to eBGP peers or to reflector clients as allowed by reflection rules. For any multi-router design, count the required sessions: n(n-1)/2 for a full mesh, or designate reflectors. Verify with show ip bgp on each router that the prefix is present and marked as valid and best.
Treating multiprotocol BGP address families as an afterthought and configuring an IPv6 or VPN neighbour without activating the correct address family, then wondering why no routes appear.
Candidates configure the neighbour under the global BGP process and assume it carries all families. In practice each address family must be activated for the neighbour, and a capability mismatch in the OPEN exchange means the family is never negotiated. VPN and EVPN add the need for the correct route-target and RD configuration on top.
What to do instead
For every neighbour, list the address families it must carry and confirm activation under each. Check the negotiated capabilities in the neighbour summary and the per-family route counts. For VPN and EVPN, verify that the route target import matches the export on the originating PE and that the RD is unique per VRF. Test with a single prefix per family before scaling.
Assuming BGP converges instantly after a link failure and not accounting for the difference between the hold timer, the KEEPALIVE interval, and the time for the IGP to reconverge underneath the BGP next hop.
Candidates learn the default timers (KEEPALIVE 60 s, hold 180 s) but do not connect them to real convergence. A dead peer is only detected when the hold timer expires, and even then the BGP next hop must be reachable through a converged IGP. Fast external failover, BFD, and next-hop tracking are the mechanisms that shorten this, and they are often omitted from the answer.
What to do instead
For any convergence question, build a timeline: physical failure, IGP detection and reconvergence, BGP next-hop invalidation, best-path recomputation, and advertisement to peers. Then name the mechanism that shortens each stage: BFD for fast detection, next-hop tracking, and tuned timers where appropriate. State the trade-off of aggressive timers (false positives and CPU load) rather than just lowering them.
Answering a service-provider design question with a generic 'use a route reflector' or 'use a peer group' without stating the scaling problem being solved, the placement of the reflectors, and the policy boundaries between customer, peer, and transit.
Candidates know the vocabulary of SP design but not the reasoning. They cannot explain why a full mesh does not scale, why peer groups reduce configuration and update-generation load, or why customer routes are preferred over peer routes and peer routes over transit. The result is an answer that names a feature but does not solve the scenario.
What to do instead
Frame every SP design answer around three questions: what is the scaling limit, where does the policy boundary sit, and how is loop prevention enforced. State the standard preference order (customer, then peer, then transit) and the community or local-preference mechanism that implements it. Justify reflector placement by client count and path diversity, and explain peer groups as both a configuration and an update-generation optimisation.
Reading only the local routing table when troubleshooting and not comparing what was received, what was selected, and what was advertised to each neighbour.
Candidates jump to the global routing table, which shows only the selected route. They miss that the problem may be an inbound filter, an unselected but present route, or a route that is selected locally but suppressed outbound. The three views answer different questions and must be compared.
What to do instead
Adopt a fixed troubleshooting order: confirm the session is Established, list received routes for the prefix, identify the best route and the reason it won, then list advertised routes per neighbour. Use the per-neighbour advertised-routes view and the received-routes view (with soft reconfiguration or route refresh) rather than guessing. Only after those three views agree should you change configuration.
Believing that changing a policy takes effect immediately without a route refresh or a soft reset, and then concluding the policy is wrong when the old advertisement persists.
Outbound policy changes generally take effect on the next advertisement, while inbound policy changes need a refresh from the peer unless soft reconfiguration stores the unmodified routes. Candidates change a route-map, see no change, and revert a correct configuration. Hard resets are then used unnecessarily, causing a real outage.
What to do instead
Before changing policy, know whether the change is inbound or outbound and whether the peer supports route refresh. Prefer a soft refresh over a hard reset, and never hard-reset a production session without checking the impact. After the change, verify the received or advertised table for the specific prefix and confirm the expected attribute values, not just the presence of the route.