Brocade Network OS Administrator’s Guide v4.1.1 - Manual (Page 624)

The device compares the MEDs of two otherwise equivalent paths if and only if the routes were
learned from the same neighboring AS. This behavior is called deterministic MED. Deterministic
MED is always enabled and cannot be disabled.
To ensure that the MEDs are always compared, regardless of the AS information in the paths, the
always-compare-med command can be used. This option is disabled by default.
The med-missing-as-worst command can be used to make the device regard a BGP4 route with a
missing MED attribute as the least-favorable path when the MEDs of the route paths are compared.
MED comparison is not performed for internal routes that originate within the local AS or
confederation, unless the compare-med-empty-aspath command is configured.
8. Prefer paths in the following order:
• Routes received through EBGP from a BGP4 neighbor outside of the confederation
• Routes received through EBGP from a BGP4 device within the confederation or routes received
through IBGP.
9. If all the comparisons above are equal, prefer the route with the lowest IGP metric to the BGP4 next
hop. This is the closest internal path inside the AS to reach the destination.
10.If the internal paths also are the same and BGP4 load sharing is enabled, load-share among the
paths. Otherwise go to Step 11.
NOTE
For EBGP routes, load sharing applies only when the paths are from neighbors within the same
remote AS. EBGP paths from neighbors in different ASs are not compared, unless multipath multi-
as is enabled.
11.If compare-routerid is enabled, prefer the path that comes from the BGP4 device with the lowest
device ID. If a path contains originator ID attributes, then the originator ID is substituted for the
router ID in the decision.
12.Prefer the path with the minimum cluster-list length.
13.Prefer the route that comes from the lowest BGP4 neighbor address.
BGP limitations and considerations
The following limitations and considerations apply to BGP support on Network OS platforms:
• IPv6 is not supported.
• VRF functionality is not supported.
• There is no backward compatibility. In case of a downgrade, BGP configurations are lost.
• There is no support for graceful restart or nonstop routing. Following a failover or switchover, BGP
routes and active neighbors are lost. However, the configuration is restored with a restart.
• RASLogs are generated when a BGP session begins.
• RASTRACE logs are available with module ID "261 BGP".
Understanding BGP configuration fundamentals
This section provides an overview of the configuration considerations and basic steps required to
enable BGP functionality. Examples are provided in
Configuring BGP on page 636.
Similar to other Layer 3 protocols in Network OS, BGP is supported only in the VCS mode of
operation. Each RBridge in a VCS fabric running BGP acts as an individual BGP device. BGP can
form IBGP peering with other RBridges in the same VCS fabric running BGP.
BGP limitations and considerations
624 Network OS Administrator’s Guide
53-1003225-04