Официален блог на WebEKM EKM очаквайте сайта онлайн скоро.
Download Free Templates http://bigtheme.net/ free full Wordpress, Joomla, Mgento - premium themes.
BGP – neighborhood establishing, routes injecting and BGP table understanding
In this artcile we will focus on fundamental and crucial features of BGP neighborhood establishing and routes injecting into BGP processes, we also break BGP table down for better understanding.
NEIGHBORHOOD
iBGP neighborhood
iBGP neighborhood has to be configured between all routers within the AS, if the AS is a transient AS due to Split Horizon (“Don’t send an update that you got to the other iBGP routers”).Transient AS means we border with at least 2 other autonomous systems and we pass prefixes between them. Despite we have connectivity between all iBGP, we have no loops because there is BGP Split Horizon mechanism, that doesn’t allow iBGP sends updates that they learned, because updates are being sent to all other iBGP routers in the same time.
eBGP neighborhood
Requirements for routers to become peers
– must be reachable via IGP or static routing (exact route has to be placed in the routing table, default route 0.0.0.0 0.0.0.0 doesn’t work)
– the BGP router ID of 2 routers must not be the same
– if configured md5 authentication must pass
– IP addresses have to match on interfraces and in neighbor command
The neighborhood between 2 eBGP may be established in 2 ways :
– on physical interfaces, then we have to use static routes or we may use underlying
protocol like OSPF and redistribution
– with using loopbacks; because 2 neighbors assume that are directly connected and use TTL of one,in order to establish neighborhood we have to use command “ebgp-multihoop” in order to say that there is more than one hop. We also have to point out loopback interfaces as sources of updates.
Neighborhood adjency states:
IDLE – process is administratively down or awaiting the next retry attempt. IDLE takes place when we just ordered establishing neigborhood, reseted working connection or the router is listening for connection from remote router. If successful then goes to CONNECT state.
CONNECT – process is waiting for the TCP 3 way handshake to be completed, if not then goes to ACTIVE state if yes then goes to OPENSENT
ACTIVE – the TCP connection failed, Connect-retry timer is running, listening for incoming TCP connection or router tries to establish another TCP 3 way handshake.
OPENSENT – the TCP connection exists, and BGP Open message has been sent to the peer, but the matching “Open message” has not yet been received from the other router. In this state BGP knows if it will be eBGP or iBGP
OPENCONFIRM – an open mesage has been both sent to and received from the other router, also BGP neighbors send to each other keepalive messages.
ESTABLISHED – all neighbors parameters match, the relationship works.
When an eBGP router receives an update and it contains the AS_Path attribute with its own ASN, the router ignores that route, because that means a loop. Router only takes into consideration routes with AS_PATH attribute that doesn’t contain its own ASN. This is built-in BGP loop prevention mechanism.
Next Hop issue
Between eBGP routers the next hop is being changed, but between iBGP is not. This is why we have to change next hope behaviour regarding each iBGP router within our AS. eBGP Router in AS 1 advertise network 1.1.10.0/24 with next hope itself 50.0.0.1, eBGP router is directly connected, so know very well how to reach next hop, but passes information about network 1.1.10.0/24 to iBGP peers in its AS with the same next hope 50.0.0.1. iBGP router doesn’t have a clue how to reach 50.0.0.1 and we got next hop resolution problem.
So, we have to configure on the edge BGP2 router towards iBGP routers:
neighbor [R1] next-hop-self
neighbor [R2] next-hop-self
If you see networks in ‘ip bgp topology’ but there is no ‘>’ best mark beside any of them,and what is the aftermath you don’t see this prefixes in the routing table, that may means there is a problem with a ‘next hop’, command hasn’t been run on the eBGP router.
ROUTES INJECTING
Defining neighborhood only, has no influence on routing table, the routes have to be injected into BGP process somehow. We may do this in 3 ways:
– by “network” command, the route has to be placed in the routing table before, it doesn’t matter how a route got into the routing table, but can’t via BGP process. Routes injected via “network” command get higher preference than the same, injected via redistribution process or aggregate-address command
network 192.168.10.0 mask 255.255.255.0
– by redistribution command, there is no seed metric like in EIGRP or OSPF !
– by using route summarization (aggregation) . Routes that are going to be summarized have to be placed in the routing table.
aggregate-address prefix prefix-lenght [summary-only]
summar-only causes that in the routing table will show up only summarized network, if we will not use summary-only then in the routing table we find summarized network address and all routes that have been summarized
Routes originated from iBGP have advertised distance 200 routes from eBGP 20
What we may find in ip BGP table ?
* – valid route, may be installed in routing table
> – the best bgp route
r – RIB failures There may be 3 reasons that given network doesn’t appear in the routing table :
1.Router knows the route with better AD, e.g. static route
2.Memory failure (not enough memory for all BGP prefixes)
3.Maybe the size of the routing table has been limited we may limit the number of routes if we use VFRs
i – internal route, iBGP neighbor has advertised this network to us, if there is no “i” means route has been learned from eBGP peer, unless the next hop is 0.0.0.0
Next Hop – if there is 0.0.0.0 means the route in BGP table is thanks to IGP or has been added statically it is so called locally originated route, non BGP route
Path – the path to the network, AS the most on the left is the AS that we border with.Origin code “i” – means that network has been injected originally via “network” command on remote router. “?” – the route has been redistributed into BGP process on remote router (origin code)
The Rule of Synchronization
Do not consider an iBGP-learned route as “the best” unless the same prefix has been learned via IGP and is currently in the IP routing table. What means, that iBGP router can’t use the network if it doesn’t exist in its routing table as an IGP route. Take a look on the below diagram. Let’s asume we have 2 iBGP neighbors . As underlying protocol we OSPF and we create neighborhood between R1 and R3 on the loopbacks. R3 on the right advertises route 20.20.20.0/24 via iBGP session to R1. Between them there is a router that doesn’t have a clue about that network because is not running iBGP, only OSPF. R1 wants to send packet to R3 destined to network 20.20.20.0/24 but the next hope is R2 . R2 gets packet destined to network 20.20.20.0/24 and rejects its becasue doesn’t run BGP and doesn’t have network 20.20.20.0/24 in its routing table. This is why Synchronization rule has been made up. You didn’t find the iBGP network that you got of the neighbor in your IGP routing table ? Don’t use and advertise its ! The prevention mechanism against black holes is full mesh topology and running iBGP on all routers. Nowadays BGP Synchronization rule is switched off by default.
