Nokia BGP for Internet Routing common mistakes
Nokia BGP for Internet Routing · Understand the traps and how to avoid them.
When asked which path wins, the candidate compares the BGP attributes in the order they appear in the configuration or in a show command output, rather than applying the standard decision sequence (weight, local preference, locally originated, AS path length, origin, MED, eBGP over iBGP, IGP metric to next hop, oldest route, lowest router ID, lowest peer address).
The attributes are displayed in a fixed order in Nokia SR OS output, and candidates memorize the display layout instead of the decision order. They also forget that weight and local preference are evaluated before AS path length, so a longer AS path with higher local preference still wins.
What to do instead
Build a written decision-order ladder and rehearse it against five or six mixed scenarios where each tie-breaker decides the winner. For each scenario, state explicitly which attributes tied and which one broke the tie. In SR OS, practice reading the tie-breaker information shown by the path-selection output and confirm your manual answer matches the router's chosen path.
The candidate treats a BGP session that reaches Established as proof that routes will be exchanged and installed, without checking that the address families were negotiated, that the peer is configured for the correct family, and that the received routes pass the import policy and are eligible for best-path selection.
Session state and route exchange are separate layers. A peer can be Established for IPv4 unicast while the candidate expects IPv6 routes, or routes can be received but rejected by an import policy or held as invalid due to an unreachable next hop. Candidates who only look at session state miss these.
What to do instead
For every troubleshooting scenario, walk a fixed checklist: session state, negotiated families, number of routes received, number of routes accepted after import policy, and next-hop reachability in the routing table. In SR OS, compare the received, accepted, and active route counts for the peer and family, and check the peer's configured family list.
The candidate assumes that a route reflector reflects every route it receives, forgetting that it only reflects the best route per prefix to clients and non-clients, and that it does not change the attributes that affect the receiving client's own decision (such as next hop, local preference, or MED) except for adding the originator ID and cluster list.
Route reflection is often taught as a simple relay. The per-prefix best-route behavior, the role of the cluster ID and cluster list in loop prevention, and the fact that a client still runs full best-path selection on the reflected route are easy to gloss over.
What to do instead
Study one prefix through a three-level reflector hierarchy and trace exactly which routes are reflected to which peers. Practice explaining why a client may still prefer a locally originated route over a reflected one, and how a duplicate cluster ID causes reflection loops to be dropped. Verify with the originator ID and cluster list shown for received routes in SR OS.
The candidate applies an export policy that matches on a neighbor or sets attributes without confirming that the policy is attached in the correct direction and to the correct peer group, so routes are filtered on the wrong session or not filtered at all.
Import and export policy direction is a frequent source of confusion, and peer-group inheritance in SR OS means a policy set at group level may be overridden or shadowed by a peer-level policy. Candidates also forget that an export policy controls what is advertised, not what is installed locally.
What to do instead
For each policy task, write down three things before configuring: direction, peer or group, and expected effect on the advertised or accepted route count. Then verify by comparing the peer's advertised-route count before and after, and by checking which policy is actually in effect for that peer rather than assuming group inheritance.
The candidate configures a multihomed design and expects inbound traffic to follow the link with the better local preference or the shorter AS path, not realizing that inbound traffic is controlled by the remote AS and that local preference affects only outbound selection.
Local preference is the most visible knob in the decision process, so candidates reach for it when asked to influence inbound traffic. They also confuse MED, which is a hint to the neighboring AS, with a guarantee.
What to do instead
Separate the two directions explicitly in every answer: outbound uses local preference, AS path prepending, and MED sent to the neighbor; inbound requires influencing the remote side through AS path prepending, community-based policy agreed with the provider, or prefix advertisement strategy. State which side controls the decision for each technique you propose.
The candidate describes prefix filtering as a single step and forgets that a full inbound policy must also cap the prefix length, reject the default route and the local AS in the AS path, and reject bogon and reserved ranges, and that an outbound policy must not leak transit routes learned from one provider to another.
Prefix lists are the most familiar tool, so candidates stop at 'filter what the provider should send' and omit the leak-prevention and sanitization parts that the exam treats as part of a complete security posture.
What to do instead
Write inbound and outbound policy templates as checklists: inbound rejects default and overly long prefixes, rejects paths containing your own AS, rejects bogons and unallocated space, and accepts only the provider's documented aggregates; outbound advertises only your own aggregates and never routes learned from another provider. Rehearse applying the same template to a customer and to a peer.
The candidate configures IPv6 BGP by adding an address family but leaves the transport session on IPv4, then cannot explain why IPv6 routes are not exchanged, or assumes that an IPv4 session automatically carries IPv6 unicast.
Multiprotocol BGP allows a session over one address family to carry routes for another, but only if both peers negotiate the IPv6 unicast family. Candidates conflate the transport address with the carried family.
What to do instead
Distinguish transport from carried family in every answer. State whether the session is IPv4 or IPv6 and which families are negotiated on it. In SR OS, confirm that the neighbor has the IPv6 family enabled and that the peer advertises it, and check the received and active counts for the IPv6 family separately from IPv4.
The candidate tunes BGP timers to speed convergence without accounting for the effect on session stability, or proposes reducing the hold time below what the peer or the platform supports, and does not mention that faster timers increase the chance of a session flap under load.
Timers are easy to change in configuration, so candidates treat a lower keepalive and hold time as a free improvement. They forget that a flapping session causes route withdrawal and re-advertisement, which can be worse than slow detection.
What to do instead
For each timer question, state the trade-off explicitly: detection speed versus stability and CPU load. Mention that hold time must be at least three times the keepalive in normal practice, that both peers negotiate the lower value, and that BFD or a graceful-restart mechanism is often a better answer than aggressive timers. Confirm the negotiated timers on the session in SR OS.
The candidate reads a route as 'valid' and assumes it is installed, without checking that the next hop resolves in the routing table, that the route is the best path among candidates, and that the route is not held by a dampening or maximum-prefix limit.
The status flags on a BGP route are numerous and candidates learn only the common ones. A route can be received and accepted but remain unusable because the next hop is unreachable or because it lost best-path selection to another path.
What to do instead
Practice reading the full route entry in SR OS: status flags, next-hop resolution, peer, and whether the route is marked as the best path. For any 'route is missing' scenario, check in order: received, accepted by policy, next-hop reachable, best path, and installed in the forwarding table. Also check maximum-prefix and dampening state for the peer.
The candidate describes iBGP scaling only in terms of full mesh and route reflectors, and cannot explain when confederations are appropriate, how confederation sub-AS numbers appear in the AS path, and why confederations are visible to external peers differently from route reflectors.
Confederations are less commonly deployed, so candidates skip them and lose the comparison questions. They also forget that confederation sub-AS hops are removed from the AS path before advertisement to true external peers, and that the confederation identifier is what external peers see.
What to do instead
Build a comparison table of full mesh, route reflector, and confederation covering configuration complexity, loop prevention mechanism, and what an external peer sees in the AS path. Rehearse one migration scenario from full mesh to reflectors and one to confederations, and state the exact AS path an external peer would observe in each case.