BGP Overview
Open Standards Based
- RFC 4271 " A Border Gateway Protocol 4 (BGP-4)" (text | pdf | html)
Classless path vector routing protocol
- Uses multiple "atributes" / Rich metric (Path attributes) for routing decision
- Supports VLSM and summarization
- Reliable updates / Triggered updates only.
- Scalable to massive networks.
- Extensible
* IPv4 Multicast, IPv6, MPLS, etc.
BGP ASNs
- Autonomous System (AS)
- "... a set of routers under a single technical administration, using an interior gateway protocol (IGP) and common metrics to determine how to route packets within the AS, and using an inter-AS routing protocol to determine how to route packets to other ASes." (RFC 4271) (text | pdf | html)
ASNs are allocated by Internet Assigned Numbers Authority (IANA)
- http://www.iana.org/numbers/
- ASN Values
Originally 2-Byte field
- Values 0 - 65535
- Public ASNs 1 - 64511
- Private ASNs 64512 - 65535
Currently 4-byte field
- RFC 4893 "BGP Support for Four-octet AS Number Space" (text | pdf | html) - IOS support as of 12.4(24)T
- 0.0 to 65535.65365 notation
- 0.[0-65535] denote original 2-Byte ASNs
Requires backwards compatibility with old code
- 4 Byte ASN support negotiated during capability exchange
- "Old" BGP speakers are sent ASdot numbers encoded as ASN "23456"
- Real AS-Path encoded with optional transitive attributes AS4_AGGREGATOR and AS_PATH
Establishing BGP Peerings
Like IGP, first step in BGP is to find neighbors to exchange information with.
Unlike IGP...
- BGP does not have its own transport
- BGP has different type of neighbors
- BGP neighbors are not discovered
- BGP neighbors do not have to be connected
BGP Transport
BGP uses TCP port 179 for transport
- Implies that BGP needs IGP first
BGP neighbor statement tells process to...
- Listen for remote address via TCP 179
- Initiate a session to remote address via TCP 179
- If collision, higher router-id becomes TCP client
TCP server must agree on where client's session is coming from
- If server does not expect session it will refuse
Client's packet is sourced from outgoing interface in the routing table
- Can be modified with update-source per neighbor
Demonstration
- Idle State:
- Refuse all incoming BGP connections
- Start the initialization of event triggers.
- Initiates a TCP connection with its configured BGP peer.
- Listens for a TCP connection from its peer.
- Changes its state to Connect.
- If an error occurs at any state of the FSM process, the BGP session is terminated immediately and returned to the Idle state. Some of the reasons why a router does not progress from the Idle state are:
- TCP port 179 is not open.
- A random TCP port over 1023 is not open.
- Peer address configured incorrectly on either router.
- AS number configured incorrectly on either router .
- Connect State:
- Waits for successful TCP negotiation with peer.
- BGP does not spend much time in this state if the TCP session has been successfully established.
- Sends Open message to peer and changes state to OpenSent.
- If an error occurs, BGP moves to the Active state. Some reasons for the error are:
- TCP port 179 is not open.
- A random TCP port over 1023 is not open.
- Peer address configured incorrectly on either router.
- AS number configured incorrectly on either router.
- Active State:
- If the router was unable to establish a successful TCP session, then it ends up in the Active state.
- BGP FSM tries to restart another TCP session with the peer and, if successful, then it sends an Open message to the peer.
- If it is unsuccessful again, the FSM is reset to the Idle state.
- Repeated failures may result in a router cycling between the Idle and Active states. Some of the reasons for this include:
- TCP port 179 is not open.
- A random TCP port over 1023 is not open.
- BGP configuration error.
- Network congestion.
- Flapping network interface.
- OpenSent State:
- BGP FSM listens for an Open message from its peer.
- Once the message has been received, the router checks the validity of the Open message.
- If there is an error it is because one of the fields in the Open message doesn’t match between the peers, e.g., BGP version mismatch, MD5 password mismatch, the peering router expects a different My AS, etc. The router then sends a Notification message to the peer indicating why the error occurred.
- If there is no error, a Keepalive message is sent, various timers are set and the state is changed to OpenConfirm.
- OpenConfirm State:
- The peer is listening for a Keepalive message from its peer.
- If a Keepalive message is received and no timer has expired before reception of the Keepalive, BGP transitions to the Established state.
- If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions back to the Idle state.
- Established State:
- In this state, the peers send Update messages to exchange information about each route being advertised to the BGP peer.
- If there is any error in the Update message then a Notification message is sent to the peer, and BGP transitions back to the Idle state.
- If a timer expires before a Keepalive message is received, or if an error condition occurs, the router transitions back to the Idle state.
- External BGP (EBGP) Peers
- Internal BGP (iBGP) Peers
- Update and path selection rules change depending on what type of peer a route is being sent/received from
- EBGP Peering Rules
EBGP packets default to TTL 1
- Can be modified if neighbors are multiple hops away
Non multi-hop peers must be directly connected by default
- Can be modified if connected neighbors peer via Loopbacks
Loop prevention via AS-Path
- Local ASN is "prepended" to outbound updates
- Inbound updates containing local ASN are discarded
- Can be modified with neighbor allowas-in
Next-hop Processing
- Outbound EBGP updates have local update-source set as next-hop
- E.g. if update-source is Loopback0, next-hop is Loopback0
- E.g "Third Party" next-hop
- iBGP Peering Rules
iBGP packets default to TTL 255
- Implies neighbors do not have to be connected as long as IGP reachability exists
Loop prevention via route filtering
- iBGP learned routes cannot be advertised on to another iBGP neighbor
- Implies need for either:
- Fully meshed iBGP peerings
- Route reflection
- Confederation
Next-hop Processing
- Outbound iBGP updates do not modify the next-hop attribute regardless of iBGP peer type
- iBGP peer
- Route Reflector's client peer
- Route Reflector's non-client peer
- Confederation EBGP peer
BGP Route Reflectors
- Eliminates need for full mesh
- Only need peering(s) to the RR(s)
- Like OSPF DR & IS-IS DIS, minimizes prefix replication
- Send one update to the RR
- RR sends the update to its "clients"
- Loop prevention through Cluster-ID
- RR discards routes received with its own Cluster-ID
- Does not modify other attributes such as next-hop
Route reflector can have three types of peers
- EBGP peers
- Neighbor in different AS
- iBGP peers with route-reflector-client
- iBGP peers without route-reflector-client
RR processes updates differently depending on what type of peer they came from:
- EBGP learned routes:
- Can be advertised to EBGP peers, Clients, & Non-Clients
- Can be advertised to EBGP peers, Clients, & Non-Clients
- Can be advertised to EBGP peers, & Clients
RR placement based upon these rules
Large Scale BGP Route Reflectors with Clusters
- Larger scale BGP designs cannot be serviced by only a single RR
- Single RR is a single point of failure
- Cluster is defined by the clients a RR serves
- RRs in the same cluster use the same Cluster-ID
- Depends on redundancy design
- Inside Sub-AS full mesh or RR requirement remains
- Between Sub-AS acts like EBGP
- Sub-AS numbers are stripped from advertisements to "true" EBGP peers
- BGP Confederation Configuration
- Enable the BGP process
- router bgp [sub-as]
- bgp confederation-id [main-as]
- bgp confederation-peers [sub-as1 sub-asX]
- Not all Sub-ASes, just those directly peered with
- BGP NLRI can be originated by:
- network statement - Requires exact match in the routing table first
- redistribute statement - Won't include OSPF External by default
- aggregate-address statement - Requires one subnet in BGP table first
- bgp inject-map statement - Opposite of aggregation
BGP Network Statement
- Originates prefixes with ORIGIN of IGP (i)
- Requires exact match in the routing table - Does not have to be a connected prefix, can be learned via IGP
- Without mask keyword assumes classful mask
BGP Redistribute Statement
- Originates prefixes with ORIGIN of INCOMPLETE (?)
- Originates classful summary if auto-summary is enabled
- Automatically copies IGP metric to BGP MED
- Won't include OSPF External by default - redistribute ospf [pid] match internal external
BGP Aggregation
- Can be applied at any point in the network as long as one subnet is in the BGP table
- Configured as aggregate-address [network][mask][args]
- Arguments are: - summary-only
- suppress-map
- attribute-map | route-map
- as-set
- advertise-map
BGP Conditional Route Injection
- Originates subnet(s) from aggregate for purpose of longest match traffic engineering
- Configured as bgp inject-map inject-map exist-map exist-map [copy-attributes] - Inject Map
- Subnet to be advertised
- set ip address prefix-list[list]
- Aggregate to be originated from
- Match ip address prefix-list [list]
- Match ip route-source prefix-list [list]
No comments:
Post a Comment