I've started a new series called 'Quick Study Notes' on Twitter, since I haven't had the time, energy, or motivation to work on my blog posts and videos recently. I've also decided to collect them on my blog after a period of time, perhaps weekly. Here is my first batch.
BGP Origin codes:
BGP is not a routing protocol alone. BGP does not have its own transport protocol. BGP is an application and it uses TCP port 179. This implies that some form of underlying IP reachability must already be in place before BGP sessions can be established.
BGP uses normal client-server communication. One session is required between two BGP peers. If both initiate BGP connections at the same time, the session from the device with the higher BGP router ID is maintained and the other connection is dropped.
The TCP client/server selection can be controlled with the update-source configuration or transport connection-mode [active | passive] command. Example: if R1 sets the update-source and R2 does not, then R1 is always the TCP client and R2 is always the TCP server. [Note: Using the update-source command for this purpose is not recommended but it works because it causes the connection from R2 to fail since the update-source is not set. The BGP is only successful from R1 (client) to R2 (server).]
BGP messages:
BGP session summary:
eBGP session details:
BGP states:
If a BGP connection is coming from an address not specified in the neighbor statement, the connection is refused. By default, the source address is the IP address of the outgoing interface. The source address can be changed with the update-source command.
Loop prevention in BGP:
BGP synchronization: if enabled, there must be a match for the prefix in the IP routing table before an iBGP learned route can be considered a valid path. Synchronization is disabled by default in IOS 12.2(8)T and later. Rarely, if ever, used anymore.
BGP next hop processing:
BGP Origin codes:
- i - IGP: route originated using the network statement
- e - EGP: route originated from EGP (obsolete)
- ? - incomplete: route originated using the redistribute command
BGP is not a routing protocol alone. BGP does not have its own transport protocol. BGP is an application and it uses TCP port 179. This implies that some form of underlying IP reachability must already be in place before BGP sessions can be established.
BGP uses normal client-server communication. One session is required between two BGP peers. If both initiate BGP connections at the same time, the session from the device with the higher BGP router ID is maintained and the other connection is dropped.
The TCP client/server selection can be controlled with the update-source configuration or transport connection-mode [active | passive] command. Example: if R1 sets the update-source and R2 does not, then R1 is always the TCP client and R2 is always the TCP server. [Note: Using the update-source command for this purpose is not recommended but it works because it causes the connection from R2 to fail since the update-source is not set. The BGP is only successful from R1 (client) to R2 (server).]
BGP messages:
- OPEN: sets up and establishes BGP adjacency
- UPDATE: advertises, updates, or withdraws routes
- NOTIFICATION: indicates error conditions
- KEEPALIVE: periodic message to make sure BGP neighbor is still alive
BGP session summary:
- iBGP default TTL=255. iBGP peers need not be directly connected, if there is IP reachability.
- eBGP default TTL=1. eBGP peers must be directly connected, unless other configuration [disable-connected-check | ebgp-multihop] is used.
eBGP session details:
- IOS checks if eBGP peer is directly connected. If not, the session is not even attempted. Remove the check with disable-connected-check.
- ebgp-multihop changes the default eBGP TTL (1) to another value and implicitly applies disable-connected-check.
BGP states:
- Idle: start event, listen for a connect
- Connect: TCP 3-way handshake, send OPEN
- Active: "failed Connect state", new TCP 3-way handshake
- OpenSent: wait for OPEN from peer
- OpenConfirm: wait for KEEPALIVE or NOTIFICATION
- Established: BGP peering is complete
If a BGP connection is coming from an address not specified in the neighbor statement, the connection is refused. By default, the source address is the IP address of the outgoing interface. The source address can be changed with the update-source command.
Loop prevention in BGP:
- eBGP: if the local AS is in the AS_PATH, the routes are not accepted
- iBGP: iBGP learned routes cannot be advertised to other iBGP peers (split horizon rule). Thus, all iBGP routers must peer with each other (full mesh requirement)
BGP synchronization: if enabled, there must be a match for the prefix in the IP routing table before an iBGP learned route can be considered a valid path. Synchronization is disabled by default in IOS 12.2(8)T and later. Rarely, if ever, used anymore.
BGP next hop processing:
- eBGP: The next hop is always if IP address of the BGP session (as specified in the neighbor command).
- iBGP: The next hop eBGP advertises is carried into iBGP. It is not changed for iBGP unless next-hop-self is used.
Comments
Post a Comment