Day4: BGP

09/04/2008
BGP
Path Vector Protocol, Exterior Gateway Protocol
Doesn't have its own transport uses TCP 179
Relies on IGP for basic IP reachability to route BGP, cannot use BGP alone

TIP:Make sure that when u reach to BGP section in Exam, that u read thru the entire section so that you dont have to redo the entire thing

Doesn't run on per interface basis like IGP, can be directly connected or can be remote


Confederations : Are using peering with diff AS, but not truly eBGP connection

When we say neighbor 1.2.3.4 remote-as 1000
==> we will listen for address 1.2.3.4 starting TCP session at port 179
==> Src of BGP packet, will be the interface IP
==> Server needs to agree on the src-ip to which it will accept the connection

Client uses tcp 179 as dst-port, server uses tcp 179 as the src-port

dont need to use update-source on btoh ends.
Only at the client needs it and this needs to be matched with wht is configured on the server

When we do peering with lo0, its is only for REDUNDANCY of control plane (BGP traffic), its not for load bal of data plane traffic.
Load Bal at data plane is a function of IGP.

By default TTL of BGP is 1
so if we do ebgp with non connected neighbors, we need to increase the TTL using ebgp-multihop, so that the TTL is extended to 255 (the max)
don't modify the 255 unless exam says so....

Loop Prevention: cannot accept prefix with our own AS in the path

Can be override by using neighbor [address] allow-as-in
or
neighbor [addresss] as-override


==> V.V IMP ==>When we USE EBGP, the NEXT-HOP is modified to what we set as the peering address for EBGP
We can change this via route-map if we want to

Loop prevention in IBGP:
ibgp learned routes cannot be adv to another ibgp neigh
==> take the routes directly form the ibgp rtr originating the route
==> We need full mesh ibgp peering
===> This is only for CONTROL Plane traffic, real data flow is still based on ibgp next-hop value

To avoid full mesh, we can use route-reflector
or use confederations

there has to be a full mesh ( or RR) within a confederation

in IBGP there is no next-hop modification,
==> So in IGP we need to have those routes to the next-hop as looked up by IBGP




#########Route reflectors ##############
GOAL: Take updates from ibgp neigh and send out to other iBGP neighbors
Three Roles -
-EBGP neighbor
neigh in diff as
-Client peer
neigh with router-reflector-client
-Non-client Peer
neigh without router-reflector-cleint


Update Propagation
-EBGP
to ALL
-Client
to ALL (EBGP, Client, Non-Cleinet )
-Non-Client
to EBGP and to Client, CANNOT pass to non-client

Placement based on the above rules.

Generally, good design, will have all ibgp neig as clients except the other RR



sh ip bgp cmd analysis
> besides the prefix ==> best route and will be added to routing table and will be advertised further
i besides the PATH col, suggested these were originated by using network statements
? redistribution
r RIB Failure OR we already have a better route in the Routing table with lower AD (hardly the case in real life)
if a route is NOT a best path
1) do we have route to next-hop
2) if they are ibgp route, does bgp synchronisation rule come into play



#########################Confederations ###############################
Loop prevention: AS_PATH
Confederation: Sub Autonomous System use the Private AS range, but technically they don't have to
They do that, just to ensure that other's ISP actual AS numbers are not conflicting with the AS # that we have picked

Inside confederation, we need RR or full-Mesh ibGP

Exam Tip: Ensure that u read thru the entire BGP requirement to prevent picking incorrect BGP AS Number.

sh ip bgp cmd analysis
-next hop not modified
-() confederation number in parentheses]



LAB TIP: It may not be a requirement in LAB to have reachability to BBR prefixes. If its unclear , ask the proctor