Establishing BGP Peerings
Like IGP, first step in BGP is to find neighbors to exchange information with
Unlike IGP…
- BGP deos not have its own transport protocol.
- Uses TCP port 179.
- For BGP neighbors, they will have to have IP reachability.
- BGP neighbors are not automatically discovered. We have to manually define our neighbors. BGP is policy based.
- Manually configure neighbors via neighbor statement
BGP Neighbors do not have to be connected
- IGP is always on a link-by-link basis
- BGP is a logical peering over TCP. BGP does not care where the neighbor is. There could be multiple routers in between them, along as they have TCP connectivity they will able to peer.
- Implies that BGP always needs a IGP underneath, like EIGRP or OSPF to provide the TCP transport.
BGP has different types of neighbors
External BGP vs. Internal BGP.
BGP Packet Formats
- Peering Packet Formats
Uses four types of packets
- Open
- Keepalive
- Update
- Notification
BGP Open message
Use to start the BGP peerings
Includes information such as:
BGP version – should be version 4. Everyone has to aggree on the version.
Local ASN
Local Router-ID. Must be unique.
Hold time
options – AKA capabilities.
BGP Keepalive Message
- Basic hello, to ensure neighbor is up.
- Used for dead neighbor connection
- if hold time = 0. keepalives disabled. If we use a keepalive of 0, the holdtime will be disabled.
BGP update message
- Where the actual data is going to be sent. It is where we advertise or withdraw prefixs.
- Includes withdrawn routes – some route that we want to remove from the table.
- NLRI. New routes that we are updating
- Path vector attibutes
- Attributes for each individual routes where the BGP best path selection will be used to determine the best path.
BGP Notification Message
- Used to convey error messages. If there is a problem on the link BGP will send out a notification of the error.
- if a BGP speaking router is going down and we do not hear a keepalive within the holdtime a notification will be sent.
- After notification is sent BGP session is closed.
- BGP routers do not agree on the version a notification message will be generated that the connection is going down as the version is not supported.
- unsupported optional parameter. if i am routing IPv4 and my neighbor is routing IPv6, there will be an error.
- unaccepatable hold time
- unacceptable hold time
- hold timer expired.
BGP Peering state maching
BGP state machine keeps track of the Peering establishment.
IDLE
- waiting to start 3 way handshake – TCP uses port 179 to establish a peering.
Client will send a SYN message to the server – I want to start a session with you
Server will respond with and SYN ACK
Client will then send a ACK back to state that the connection has been fully agreed.
Connect
waiting to complete 3 way handshake, we are in the process of setting up the TCP connection.
Active
3 way handshake has failed. try again. Activite state is always BAD. if we dont get pass the tcp handshake there is a problem with TCP such as an ACL filtering the TCP connection,
Open Sents
3 way handshake is complete, open message is sent. Open message is used to negotiate the attributes.
Open Confirm
open message received, everything is agreed upon.
Established
Peering complete.
if we loook at show ip bgp summary the acutal routes can now be exchanged.
debug ip bgp – will show how we progress through the state machine.
BGP Peering Types
External BGP (EBGP) Peers
- neighbors outside my Autonoums system. AS numbers do not match between routers.
Internal BGP (IBGP)
- neighbors inside my own Autonoum system. If my AS matches with your AS, then we are in the same AS.
EBGP Peerings
Peers in different Ases
We have a customer edge router, that is doing a peering with the provider edge router. If I am buying a data circuit from AT&T, I will do a direct eBGP peering up to them.
can be “multiphop” where there are multiple routers in between the acutual BGP routers who want to do the peering. Protection mechanism to protect the count to infinty, which is the TTL.
Once the eBGP neighbor is established, it will use AS-Path attribute for loop prevention.
If I advertise a route out I will put my AS in the path, if i get that route back, i will know its my own route and discard it.
If i receieve and update back from an eBGP peer with my own ASN in the AS-Path, discard it – loop prevention
iBGP peerings
Peers which belong to the same AS
Many times iBGP neighbors are not directly connected which implies IGP needed underneath to provide TCP transport. An underlying IGP protocol is needed to provide TCP transport.
If you learn a route from an iBGP peer, you should not advertise that route to another iBGP peer. Every router should be in a full mesh design. Every iBGP within the same AS must peer with each other.
BGP Peering Redundancy
BGP peering is based on TCP reachability to peer address. We have to have a solid and reliable TCP connection.
If peer addresss is unreachable, peering goes down
If IP adress of serial link is used for peering and serial link goes down, peer goes down.
For redundancy there are multiple links, If I have multiple links between R1 and R2, if 1 link goes down I will have a backup link to re route data to.
R1 and R2 peering between multiple serial links if one serial link goes down, we will not be able to re roure as the IP address assoicated with the serial link has gone down.
Using loopback addresses for peering allows re routing around link failures and adds redundancy. If any of the routers link is up, loopback can be reached.
Defined as update-source for TCP session. What IP address do you want to ues when generating the TCP connection.
Basic BGP Configuration
Enable Global BGP process
- router bgp [ASN] public AS allocated by IANA
Establish BGP peers
- neighbor [address] remote -as [remote ASN] statically configure individual peers. Based on ASN, will they be iBGP or eBGP based on ASN.
Basic BGP verification
Verify BGP peerings
- show ip bgp summary – our AS number, local ID what are my remote peers – what is their version and how many routes we are learning from them.
Verify BGP table
- show ip bgp routes are exchanged that go into the bgp table – use BGP best path selection
verify BGP table detail
- show ip bgp [network] [mask] individual prefix and their length.
verify routing tables
- show ip route [bgp] where we find the best routes from the BGP table.
iBGP Full mesh scalability
With iBGP we have to maintain a full mesh of peerings with each iBGP neighbor which does scale well if we have to many routers, it becomes unmanageable.
n* (n – 1) doesn’t scale
- 10 routers, 45 peerings
- 100 routers, 4950 peerings
- 1000 routers, 499,500 peerings
Can be fixed with two expections
- Route Reflectors
same logic as DR/DIS.
- Conferderation
Split the AS into smaller sub-ASes
Route Reflectors.
- Eliminates the need for full mesh of peerings.
- Incharge of receiving all BGP updates from iBGP neighbors and sending it back out to all other iBGP neighbors.
- We send one update to the Route Reflector, in turn the Route Reflector is responsible for sending it out to its clients, the iBGP routers.
- Each iBGP router will peer with the Route Reflector, instead of peering with every other routers.
- Breaks the Full mesh of iBGP peerings.
- Loop Prevention through CLUSTER-ID
- Cluster-ID is where the Route Reflector recieves a route update and wants to send it out to other iBGP sneighbors, once its sent out its going to add its own Cluster- ID (router-ID) and if its recieved back with its own Cluster-ID, it will discard it.
- There will be multiple route reflectors, for redunancy purposes as if one goes down everyone can be effected.
BGP Confederation
Reduces full mesh iBGP need by splitting the AS into samller Sub-Ases.
- inside Sub-AS full mesh or RR need remains. Takes our AS and breaks it into smaller sub ASes but within the small sub-as we still have to have that iBGP full mesh of peerings.
- Between Sub-AS acts like EBGP.
Devices outside the confederation do not know about the internal structure.
- when updates go out to other ASes, the Sub-AS numbers will be stipped from the updates. It will be replaced with the actual public ASN.
- Sub-AS numbers are stripped from advertisements to true eBGP peers.
Typically uses ASNs in private range
- (64512 – 65535)
BGP Peer Groups
For larger scale designs
Typically many peers share the same update policy.
iBGP neighbors share the same type of update policy.
From a Route Reflector prespective, its client will share the same updating policy
We are going to receieve updates from eBGP peers, from outside our own AS. Then we send the updates down to our Route Reflector Clients.
We have individual neighbor statements for all the iBGP peers, behind the scenes once the router runs the best path selection. it will need to generate an update message for each individual router. As we do not know if they all share the same update policy.
BGP peer groups reduce configuration and processing overhead by applying a template to the peers.
Peer group, groups neighbors together into the same update policy to reduce overhead. If I take R1 and R2 and put them in the same peer group, since the peer group has the same updating policy. the result of the best path selection is going to be the same on all three routers.
it will cut down the amount of config we need
it will also cut down on the amount of utilization that the BGP process will need.
Peer group is assigned parameters such as:
- remote-as
- route-reflector-client
-route-map
Neighbor is specified as a member of the group
- peers in a group must be either all iBGP or all eBGP.
The full internet routing table now is around 350000 routes. Which means we will have 350000 routes going down to all neighbors.
BGP Peer Group Example
router bgp 1
neighbor IBGP_PEER_GROUP peer-group
neighbor IBGP_PEER_GROUP remote-as 1
neighbor IBGP_PEER_GROUP update-source loopback 0
neighbor IBGP_PEER_GROUP route-reflector-client
neighbor IBGP_PEER_GROUP next-hop-self
neighbor 1.2.3.4 peer-group IBGP_PEER_GROUP
neighbor 5.6.7.8 peer-group IBGP_PEER_GROUP
neighbor 9.10.11.12 peer-group IBGP_PEER_GROUP
neighbor 13.14.15.16 peer-group IBGP_PEER_GROUP
we are sharing a couple of commands between the peers. We are defining who is part of our peer group.
BGP Authentication
Like IGP authentication, BGP peer authentication protects control plane against attacks and misconfigurations.
BGP is based on TCP transport, hackers can send TCP packets to attack BGP speaking routers.
Without authetication, BGP susceptible to TCP Reset attacks to drop its peers. Very similar to Dos attacks
when we are exchanging BGP messages, we have to ensure that there is authentication.
Uses MD5 authentication.
Protectes BGP sessions via the TCP MD5 signature option
Simply configured as neighbor {address} password {password}
Misc. BGP Configuration
Modify peering source address
neighbor {address} update-source {interface} everyone has to agree the source address that they are peering from.
Enabling BGP authentication
neighbor {address} password {password}
Configuring BGP peer group
neighbor {peer-grooup-name} peer-group
neighbor {peer-group-name} {attrbiutes}
neighbor {address} peer-group { peer-group-name}
Enabling Route Reflection
neighbor {address} route-reflector-client – defined based on who our clients are.
Enabling Conferderation
Enable global BGP process
router bgp {sub-ASN} – some private address
Define Global BGP Process
bgp conferderation-id {ASN} – actual BGP ASN.
Define other Sub-Ases
bgp conferderation peers {sub-ASN] – who are else is part of the sub AS.