JNCIS-SP: BGP.BGP is a path-vector protocol that is used for interdomain routing. BGP views the Internet as a collection of AS. An AS is a set of routers that operate under the same administration. BGP is a classless routing protocol that exchanges information between peers. The egp BGP is defined in RFC 4271.
BGP peering sessions.
Neighbors are manually defined and use TCP port 179. TCP provides a full-duplex connection oriented, reliable byte-stream service to BGP.
BGP neighbor states.
A start event is required to initialize BGP resources and prepare a connection to a peer.
BGP is waiting for the completion of the transport protocol. Upon success; open message is sent and state becomes Open Sent. Upon failure; listen for connection initiated by remote peer and change to active state.
BGP tries to setup TCP connection. Success; Open is sent and state becomes Open Sent. If state remains active, check cabling & peer.
- Open Sent:
BGP waits for Open message from peer. When received, it is checked for errors. Upon error; back to idle-state. No error; send keepalive.
- Open Confirm:
BGP waits for keepalive or notification. If hold-timer expires without keepalive; send notification & go to Idle. Notification received; go to established.
BGP peers can exchange Update, Notification & Keepalives. Upon receipt of an Update or Keepalive, hold time is restarted. When the hold timer expires, BGP transitions back to the idle state. When there is an error in the Update message, a Notification is sent to the peer and BGP will transition back to the idle state.
BGP message types.
The BGP messages (19-4096 octets) are the following:
• Open message:
Sent after TCP three-way handshake completion. Initiates BGP session and contains details about neighbor, supported & negotiated options.
• Update message:
Transports routing information between peers.
• Keepalive message:
Peers exchange keepalives to prevent hold-time expiration.
Signals an error. Sent upon unsupported option or when peer fails to send update or keepalive. Upon error, BGP session is closed.
Supports soft-clearing of BGP sessions by allowing a peer to readvertise routes already sent.
BGP Update messages describe a single path and list multiple prefixes reachable through that path.
BGP attributes table (RFC 1771):
- Well-known mandatory: must be supported & included in every BGP update.
AS-path, Origin and next-hop.
- Well-known discretionary: must be supported, included optionally.
Local preference, atomic aggregator.
- Optional transitive: needn’t be supported. If supported, should pass unchanged.
- Optional nontransitive: need not be supported.
MED, Cluster-list and Originator ID.
The following most-common attributes are emphasized:
Next-hop, Local preference, AS-path, Origin, MED & community.
The IP address of the BGP-peer. EBGP-peer changes attribute by default. IBGP doesn’t change next-hop by default, can be altered through policy.
BGP routes for which the next-hop is not reachable are placed into routing table as hidden.
- Local Preference (LP):
LP is used to direct all outbound traffic through a specific peer. It’s a numeric value, the higher the better.
LP can be set through configuration or policy (policy > configuration). LP is AS-wide, the value is not transmitted across EBGP links. Default LP = 100.
- AS-path attribute:
Prevents loops. AS path is null until the route is advertised out the originating AS. As the route leave the AS, the BGP routers adds the local AS to the front of the path before sending it to a peer.
AS can be prepended to discourage the use of the route. Shortest AS-path wins.
- Origin Attribute:
Describes where the original router received the route from.
Values are IGP, EGP or incomplete; 0, 1 or 2. The lowest wins. Junos default is IGP.
- MED attribute:
Used to attempt to influence traffic headed back to the AS. Lowest MED wins. If MED is missing, BGP assumes it is 0. Use the ‘metric out’ on a protocol, group or neighbor level or define a policy that sets the metric.
- Community attribute:
The BGP community attribute identifies a group of destination prefixes that share a common property. The community attribute is included as a path-attribute in BGP update messages. The community is created under the [edit community] and is referenced in a routing-policy.
BGP route selection summary.
If the next hop is reachable and no loops exist, the list is evaluated in the following order;
1. Local Preference; highest wins.
2. AS-path; shortest wins.
3. Origin code; I < E < ?
4. If route is advertised from same AS, check for lowest MED value (missing MED = 0)
5. Prefer EBGP over IBGP. If all routes are EBGP, go to step 9.
6. Use lowest IGP cost to IBGP peer;
a. use inet.3 over inet.0
b. upon tie between inet.3 & inet.0, use inet.3
c. upon tie in same routing-table, use instance with most paths installed
7. For EBGP received routes, prefer current active. Otherwise, prefer routes from peer with lowest RID.
8. Prefer path with shortest cluster length.
9. Prefer routes from peer with lowest peer ID.
Between IBGP peers, use the 'nex-hop-self' action.
BGP advertisement rules.
1. IBGP advertises routes from EBGP to other IBGP peer.
2. EBGP advertises routes from IBGP or EBGP to other EBGP peers.
3. IBGP does not advertise routes received from IBGP to IBGP.
Routers AS is configured under [edit routing-options] or under the BGP hierarchy using local AS.
If local-address to peer is not configured, the egress interface address is used.
The session must be configured as internal or external.
To advertise an aggregate:
1. configure aggregate route.
2. use routing policy 'from protocol aggregate'
In applying a BGP policy, the most specific is used; first neghbor, then group and then protocol.