This article explains how Junos selects a forwarding next hop when multiple OSPF routes with equal cost exist in the routing table but ECMP load balancing is not configured. It also explains why the selected outgoing interface may change after interface events and why the original interface is not necessarily restored.
A device receives two equal-cost OSPF routes for the same destination (for example, a default route) from two different neighbors.
Example:
Route 1 via ae25Route 2 via ae26Both routes have the same OSPF metric.ECMP load balancing is not enabled.
Initially, traffic is forwarded through ae25. After an interface flap or other configuration event, the forwarding entry changes to ae26 and continues to use that interface even after ae25 recovers.
The routing table continues to show both routes as equal cost, but only one next hop is installed in the forwarding table.
While creating the next hop based on the template/parameters provided by the protocol(here OSPF), gateways are sorted(here there are 2 gateways: one with ae26 and ae25), one of the criteria for sorting is the IFL index. Lower the ifl index, higher the preference. So in this case gateway with ae26 has lower ifl index and hence ae26 will be listed as gateway with Index 0 and ae25 will be listed as gateway with Index 1.
AE26 --> Index 0
AE25 --> Index 1
Now which gateway to be installed is based on hash. Hash is computed based on route prefix, prefix length and number of gateways and based on value obtained,
one of the gateway will be considered as selected.
For the default route:
0.0.0.0 --> route prefix
/0 --> prefix length
2 --> number of gateways
The three parameters above are used for hash and the result is Index 0. Hence AE26 is selected as the gateway for this default route.
Private IFL use itable32 method of index allocation whereas for public/global IFL's bitmap way of allocation is used.
Public/global IFL index allocation is NOT strictly sequential,it follows afirst-fit bitmap allocationstrategy that can result in non-sequential or "random" ordering depending on the allocation/deallocation history.
Depending on how indexes are allocated and freed, an index assigned later to an interface may be higher or lower than the most recently allocated index.
IFL index is assigned in kernel when the IFL object is created. The IFL index value for an IFL can change in the following cases.
1. Reboot of the box.
2. Delete and Add of the IFL from config.
This is done by user explicitly by deleting the config for the IFL and committing the same and adding the IFL config again and committing.
3. Delete and Add of the IFL due to config related processing.
This can happen due to processing of the IFD configuration or IFL configuration
IFD changes:
============
Config changes for IFD that result in delete of the IFL subtree and readding the IFL subtree back as part of config processing.
Some of these config changes for IFD are listed below (Only a subset of config changes that can result in IFL index change is listed below)
- encap changes
- MTU changes
- BYPASS_QUEUEING_CHIP
- PER_UNIT_SCHEDULER
- SHARED_SCHEDULER
- HIERARCHICAL_SCHEDULER
- LACP admin-key - used with AE
- LACP system-id - used with MC-AE
- ESI value changes
IFL changes:
Config changes for IFL that result in delete of the IFL subtree and readding the IFL subtree back as part of config processing.
Some of these config changes for IFL are listed below
- adding/removing IFL from iflset
- IFL tunnel related params
- VLAN related changes
- Underlying interface config changes for interfaces such as demnux/pp0
- addition/deletion of IFL to/from bridge-domain
- addition/deletion of IFL to/from routing-instance
- addition/deletion of IFL to/from logical-systems