Sunday, June 15, 2014

EBGP Overview, BGP Peering Types.

Lessons learned:

Open standards based
-RFC 4271, BGP 4
Classless path vector routing protocol
-Used multiple attributes fo routing decisions
-Supports VLSM and summarization
--IPv4 Mulitcast, IPv6, MPLS, etc.

BGP on Cisco’s Site:

BGP is an open standards protocol – it’s considered a path vector protocol. IGP’s are making decision based on one value, the metric to reach a destination, choosing the lowest path end to end. With BGP was originally implemented with Policy in mind where the individual attributes are on a per route based, this will determine how we route to a destination.

BGP supports VLSM and summarization. With the size of the global table growing constantly it’s important to be able summarize prefix information.
Many sites offer routers that you can login to and view the global BGP table called “route-views or route-servers.

Ex: – they’re basically just routers online that you can connect to. We can use these to check policies we’re trying to apply to our outbound advertisements as they pertain to the global internet.

EX: connect to router and login as rviews with a password or rviews…>

You can login and see on average the size of the global BGP table.

You can also get a list of Route-servers here:

Example os “s hip bgp sum” off a route-view server:
route-views>sh ip bgp summary
BGP router identifier, local AS number 6447
BGP table version is 1192614054, main routing table version 1192614054

521135 network entries using 68789820 bytes of memory  à this says we currently have 521135 entries

15209495 path entries using 790893740 bytes of memory à this says’ there are over 15209495 paths to reach these entries.

2508169/94266 BGP path/bestpath attribute entries using 421372392 bytes of memory
2166488 BGP AS-PATH entries using 86870842 bytes of memory
66927 BGP community entries using 5058824 bytes of memory
396 BGP extended community entries using 12842 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1372998460 total bytes of memory
Dampening enabled. 11709 history paths, 16038 dampened paths
BGP activity 878512/333647 prefixes, 50876541/35465181 paths, scan interval 60 secs

Neighbor        V          AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd    4       3356 7842992   73921 1192614065    0    0 4w5d       490479


BGP is extensible, it can be used for more than just IP unicast routing.



Autonomous Systems (AS) per RFC 4271 -
-A set of routers under a single technical administration, using and interior gateway protocol (IGP) and common metrics to determine how to router packets within the AS, and using and inter-AS routing protocol to determine how to route packets to other ASes,

-ASNs are allocated by Internet Assigned Numbers Authority (IANA).

In general a routing policy will apply for the AS as a whole, where the policy for AS1 is different from AS2, etc.
Note: Routers inside an AS need to reachability first, in reality BGP is not a routing protocol – it’s an application that manly designed to do two things.
It’s designed to advertise an IP Prefix and a next-hop value associated with that prefix.

The design issue - the next hop value that BGP reports must then be recused through some other IGP routing protocol. BGP will rely on EIGRP, OSPF etc. BGP is for destinations outside our network that we’re trying to reach.

The AS numbers themselves are assigned by IANA.

There’s recently been a change in the format that the AS number use:
Original 2-byte field
-Values 0 – 65535
-Public ASNs 1 – 64511
Private ASNs 64512 – 65535 (1024 addresses) Similar to RFC 1918
Currently 4- byte field
-RFC 4893 BGP Support for Four-octet AS Number Space
-IOS supports as of 12.4. (24)T

As of today almost all 2 byte field AS’s have been allocated.

4-Byte BGP ASNs

-          0.0 – 65535.65535 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” – from the perspective of the IOS versions that DO NOT support the AS4 numbers, the will see everyone that has the 4 byte value represented AS number 23456. This doesn’t mean the information will be lost.

-Real AS-Path encoded with optional transitive attributes AS4_AGGREGATOR and AS4_PATH –

Establishing BGP Peerings:
Like IGP, first step in BGP is to find neighbors to exchange information with

The actual logic BGP for establishing the updates, routing the traffic etc is the same as we use in our IGP.
For example in EIGRP and OSFP our first step is to figure out who are our neighbors on our connected links that we want to run our protocols on.
Once we find the neighbors we go through an adjacency negotiation where we define attributes, Area #, etc.
Once neighbors come up we exchange information and then we can do the path selection.

Same type logic in BGP –
First step is how do we establish the peering?

Unlike IGP….
-BGP does not have its own transport – EX: OSPF used IP protocol # 89, EIGRP # 88. BGP runs on top of TCP. This implies the BGP neighbors would have to have IGP reachability before they can peer BGP. Since BGP is a Standard TCP application, the normal Client/Server Roles of TCP are going to apply.

-BGP has different types of neighbors – IBGP – EBGP – Route reflectors, etc. this will control how updates are process and best path sections.
-BGP neighbors are not discovered – Neighbors are not dynamically discovered – unlike IGPs that use Multicast. Peerings are based on unicast neighbor statements under the process.

-BGP neighbors do not have to be connected – Because TCP is the transport protocol.

BGP Transport:
BGP uses TCP port 179 for transport
-implies the BGP needs IGP First.
BGP Neighbor statement tell 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. Can happen if client and server try to establish at same time
 Normally the client will initiate the session over port 179.

Handshake Example:
R1 -- > < --R2
1)      R1 Sends TCP Syn packet with a random Source port and a Destination port of 179 (if R2 is configured to accept the session from R1)
2)      R2 replies with the second portion of the handshake – With a TCP ACK and SYN packet (TCP SYN ACK) saying I also want to start a session.
3)      R2 will send its TCP ACK with the source port of 179 and the destination of a random negotiate value.
4)      Then R1 will reply with a TCP ACK – then the session is fully open.

Key point – is that R1 will always be sending traffic toward 179 and R2 will sending traffic from port 179.

BGP Peering types:
External BGP (EBGP) Peers
-Neighbors outside my Autonomous System
Internal BGP (iBGP) Peers
-Neighbors inside my AS
Update and path selection rules change depending on what type of peer a route is being sent to/received from.

EBGP Peering Rules:
EBGP packets default to TTL 1
-can be modified if neighbors are multiple hops away.
--#neighbor (as # ) ebgp-multihop (TTL)
--#neighbor (AS #) ttl-secuirty hops (ttl)  - Common today – used to prevent against remote TCP reset attacks.

Note: these commands are mutually exclusive - you would use one of the other, not both.

Non multi-hop peers must be directly connected by default.
-can be modified if connected neighbors peer via loopbacks
-# Neighbor disable-connected-check - This disabled the connected check, normally this would be used based on Loopback addresses.

Note: The default behavior when a router goes to establish an EBGP peering, if it looks in the routing table for the neighbors destination address and it doesn’t find a directly connected route. Then the neighbor will not send the “open” message. It won’t try to establish the 3-way-handshake.
Neighbor disable-connected-check – will disable this behavior.

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 command.  

Every time an update is send out to EBGP peers, we take out local AS number and add it to the AS path attribute that is inside that actual update.
The AS will track what AS’s this update when t through from the originator to our local AS. This can also be seen by using the “route-view” servers.

route-views>sh ip bgp        

   Network          Next Hop            Metric LocPrf Weight Path
*                         0 701 6453 15169 i

This output basically tells us that this route was originated by AS 15169 – then through 6453 and then 701. So the local peer that eh AS is received from is AS 3 701.

The number on the left most portion is the AS that we are learning the AS from, the number on the right most portion is the prefix that the AS is originated in.

Key point – whenever we send an update outbound, we will take our own AS number and out it as the first number is the AS path.
If for some reason we seen our AS number INBOUND – in the path – then we will automatically filter that update out. Basic loop prevention logic.

We can modify this with the # neighbor allowas-in command.  In cases where we have the same AS number that is separated by a different AS number in the middle.

EBGP Peering Rules:
Next-hop processing  
-Outbound EBGP updates have local update-source for neighbor set as next-hop.
-EX: if update source is loopback 0, next-hop is loopback0

Can be modified with route-map action “set ip next-hop” but typically shouldn’t
-ex 3rd party next hop.

When we send updates outbound, whatever the local address is for that peering, is going to be the next hop value that goes into the next-hop value of the route. Ex:

R1 and R2
Both routers peer via their loopback interfaces
Loopback IP
Loopback IP
R12 advertises /24 -- > when this update is advertised to R2 over the EBGP session, R2 will say the prefix /24 is reachable via the next-hop of

This implies that R2 will need an additional step in the route recursion to figure out what is the local connected interface that R2 will use in order to reach the destination

If we modify this we can use the route-map option but typically you would not use this is a normal design.
This is normally called a 3rd part next hop – this is where the local router is an update but then tell you to use some other source in the data plane
In order to get there.


R1 – sends and update to R2 for prefix and instead of using the normal next-hop value – which would be whatever the update source is from R1 to R2. We can tell R2 to user R3. (

This means the control plane for BGP is going to be between R1 and R2. But then the actual data plane (actual traffic forwarding) would be through some other device.

One of the flexible feature of BGP is that the control plane is not actually tied to the data plane.

iBGP peering Rules.

iBGP Peering 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 – most efficient for selecting correct path
-route reflection


Key note: there is no time to live on internal iBGP packets, this means the neighbors do not have to be directly connected. As
Long as there’s IGP reachability in the internal network it will allow us to establish the iBGP peering and ultimately advertise the prefixes.
Based on the next-hop process rules of iBGP, the control plane message again does not have to follow- the actual data plane forwarding.

The loop prevention for iBGP uses a very simple concept. If you learn a route form and iBGP neighbor – DON’T advertise it to another iBGP neighbor.

Next-hop processing:
-outbound iBGP updates to not modify the next-hop attribute regardless of iBGP type.
--iBGP peer
--Route reflectors client peer
--Route reflectors non-client peer
--confederation EBGP peer

Can be modified with the #next-hop-self or # route-map Action set ip next-hop
This basically mean the original entry point for the route is going to be maintained throughout all of the updates in the iBGP network.

Next hop value will always be the value that came from your EBGP neighbor to begin with. Unless we use the next-hop self-command. 

No comments:

Post a Comment