cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2086
Views
0
Helpful
8
Replies

BGP - how router knows if connect is iBGP or eBGP

Networkx
Level 1
Level 1

I wonder how it happens in term of router? How it knows neighbor will be iBGP or eBGP?

8 Replies 8

depending on whether you are peering with the same AS number or not. 

Ex : - iBGP is when you are neighbouring with another device with the same AS number whereas eBGP when the device is neighbouring with different AS number

***Please rate all the useful posts***
-Prabath

no i think i didnt explain my question well.

 

Using a different is known by me. How router makes the decision if it has to establish iBGP or eBGP.

 

The question is same like how a machine know if its sending a packet to a different network (i.e. to use a gateway) or on the same network

 

I’m not sure what you are asking as the previous poster answered your question. 

 

The router knows it’s own AS number and if the neighbor is configured with same AS number then the router knows it is an IBGP connection. 

 

Jon

At what stage during BGP neighbor ship establishment does it need to make iBGP/eBGP decision and what type of messages are exchanged?

Hello,

 

in addition to the other posts, below is the 'debug ip bgp' output from a router that establishes an iBGP and an eBGP neighborship. The message exchange is almost identical. Differences are marked in bold:

 

iBGP

 

*Jul 10 08:00:15.639: BGP: 192.168.12.1 passive open to 192.168.12.2
*Jul 10 08:00:15.640: BGP: Fetched peer 192.168.12.1 from tcb
*Jul 10 08:00:15.640: BGP: 192.168.12.1 passive went from Idle to Connect
*Jul 10 08:00:15.640: BGP: ses global 192.168.12.1 (0x10E58470:0) pas Setting open delay timer to 60 seconds.
*Jul 10 08:00:15.653: BGP: ses global 192.168.12.1 (0x10E58470:0) pas read request no-op
*Jul 10 08:00:15.655: BGP: 192.168.12.1 passive rcv message type 1, length (excl. header) 38
*Jul 10 08:00:15.655: BGP: ses global 192.168.12.1 (0x10E58470:0) pas Receive OPEN
*Jul 10 08:00:15.656: BGP: 192.168.12.1 passive rcv OPEN, version 4, holdtime 180 seconds
*Jul 10 08:00:15.656: BGP: 192.168.12.1 passive rcv OPEN w/ OPTION parameter len: 28
*Jul 10 08:00:15.657: BGP: 192.168.12.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Jul 10 08:00:15.657: BGP: 192.168.12.1 passive OPEN has CAPABILITY code: 1, length 4
*Jul 10 08:00:15.657: BGP: 192.168.12.1 passive OPEN has MP_EXT CAP for afi/safi: 1/1
*Jul 10 08:00:15.658: BGP: 192.168.12.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Jul 10 08:00:15.658: BGP: 192.168.12.1 passive OPEN has CAPABILITY code: 128, length 0
*Jul 10 08:00:15.658: BGP: 192.168.12.1 passive OPEN has ROUTE-REFRESH capability(old) for all address-families
*Jul 10 08:00:15.659: BGP: 192.168.12.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Jul 10 08:00:15.659: BGP: 192.168.12.1 passive OPEN has CAPABILITY code: 2, length 0
*Jul 10 08:00:15.660: BGP: 192.168.12.1 passive OPEN has ROUTE-REFRESH capability(new) for all address-families
*Jul 10 08:00:15.660: BGP: 192.168.12.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Jul 10 08:00:15.661: BGP: 192.168.12.1 passive OPEN has CAPABILITY code: 70, length 0
*Jul 10 08:00:15.661: BGP: ses global 192.168.12.1 (0x10E58470:0) pas Enhanced Refresh cap received in open message
*Jul 10 08:00:15.661: BG
R2(config-if)#P: 192.168.12.1 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Jul 10 08:00:15.661: BGP: 192.168.12.1 passive OPEN has CAPABILITY code: 65, length 4
*Jul 10 08:00:15.662: BGP: 192.168.12.1 passive OPEN has 4-byte ASN CAP for: 1
*Jul 10 08:00:15.663: BGP: 192.168.12.1 passive rcvd OPEN w/ remote AS 1, 4-byte remote AS 1
*Jul 10 08:00:15.663: BGP: ses global 192.168.12.1 (0x10E58470:0) pas Adding topology IPv4 Unicast:base
*Jul 10 08:00:15.664: BGP: ses global 192.168.12.1 (0x10E58470:0) pas Send OPEN
*Jul 10 08:00:15.665: BGP: ses global 192.168.12.1 (0x10E58470:0) pas Building Enhanced Refresh capability
*Jul 10 08:00:15.665: BGP: 192.168.12.1 passive went from Connect to OpenSent
*Jul 10 08:00:15.666: BGP: 192.168.12.1 passive sending OPEN, version 4, my as: 1, holdtime 180 seconds, ID 2020202
*Jul 10 08:00:15.666: BGP: 192.168.12.1 passive went from OpenSent to OpenConfirm
*Jul 10 08:00:15.677: BGP: 192.168.12.1 passive went from OpenConfirm to Established
*Jul 10 08:00:15.678: BGP: ses global 192.168.12.1 (0x10E58470:1) pas Assigned ID
*Jul 10 08:00:15.680: BGP: nbr global 192.168.12.1 Stop Active Open timer as all topologies are allocated

*Jul 10 08:00:15.682: BGP: ses global 192.168.12.1 (0x10E58470:1) Up
*Jul 10 08:00:15.682: %BGP-5-ADJCHANGE: neighbor 192.168.12.1 Up
*Jul 10 08:00:15.709: BGP_Router: unhandled major event code 128, minor 0

 

eBGP

 

*Jul 10 08:01:54.891: BGP: 192.168.23.3 passive open to 192.168.23.2
*Jul 10 08:01:54.891: BGP: Fetched peer 192.168.23.3 from tcb
*Jul 10 08:01:54.892: BGP: 192.168.23.3 passive went from Idle to Connect
*Jul 10 08:01:54.892: BGP: ses global 192.168.23.3 (0x10E57368:0) pas Setting open delay timer to 60 seconds.
*Jul 10 08:01:54.900: BGP: ses global 192.168.23.3 (0x10E57368:0) pas read request no-op
*Jul 10 08:01:54.906: BGP: 192.168.23.3 passive rcv message type 1, length (excl. header) 38
*Jul 10 08:01:54.906: BGP: ses global 192.168.23.3 (0x10E57368:0) pas Receive OPEN
*Jul 10 08:01:54.907: BGP: 192.168.23.3 passive rcv OPEN, version 4, holdtime 180 seconds
*Jul 10 08:01:54.907: BGP: 192.168.23.3 passive rcv OPEN w/ OPTION parameter len: 28
*Jul 10 08:01:54.907: BGP: 192.168.23.3 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Jul 10 08:01:54.908: BGP: 192.168.23.3 passive OPEN has CAPABILITY code: 1, length 4
*Jul 10 08:01:54.908: BGP: 192.168.23.3 passive OPEN has MP_EXT CAP for afi/safi: 1/1
*Jul 10 08:01:54.908: BGP: 192.168.23.3 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Jul 10 08:01:54.908: BGP: 192.168.23.3 passive OPEN has CAPABILITY code: 128, length 0
*Jul 10 08:01:54.909: BGP: 192.168.23.3 passive OPEN has ROUTE-REFRESH capability(old) for all address-families
*Jul 10 08:01:54.909: BGP: 192.168.23.3 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Jul 10 08:01:54.909: BGP: 192.168.23.3 passive OPEN has CAPABILITY code: 2, length 0
*Jul 10 08:01:54.909: BGP: 192.168.23.3 passive OPEN has ROUTE-REFRESH capability(new) for all address-families
*Jul 10 08:01:54.909: BGP: 192.168.23.3 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Jul 10 08:01:54.910: BGP: 192.168.23.3 passive OPEN has CAPABILITY code: 70, length 0
*Jul 10 08:01:54.910: BGP: ses global 192.168.23.3 (0x10E57368:0) pas Enhanced Refresh cap received in open message
*Jul 10 08:01:54.910: BG
R2(config-if)#P: 192.168.23.3 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Jul 10 08:01:54.911: BGP: 192.168.23.3 passive OPEN has CAPABILITY code: 65, length 4
*Jul 10 08:01:54.911: BGP: 192.168.23.3 passive OPEN has 4-byte ASN CAP for: 2
*Jul 10 08:01:54.911: BGP: 192.168.23.3 passive rcvd OPEN w/ remote AS 2, 4-byte remote AS 2
*Jul 10 08:01:54.913: BGP: ses global 192.168.23.3 (0x10E57368:0) pas Adding topology IPv4 Unicast:base
*Jul 10 08:01:54.913: BGP: ses global 192.168.23.3 (0x10E57368:0) pas Send OPEN
*Jul 10 08:01:54.914: BGP: ses global 192.168.23.3 (0x10E57368:0) pas Building Enhanced Refresh capability
*Jul 10 08:01:54.915: BGP: 192.168.23.3 passive went from Connect to OpenSent
*Jul 10 08:01:54.915: BGP: 192.168.23.3 passive sending OPEN, version 4, my as: 1, holdtime 180 seconds, ID 2020202
*Jul 10 08:01:54.915: BGP: 192.168.23.3 passive went from OpenSent to OpenConfirm
*Jul 10 08:01:54.931: BGP: 192.168.23.3 passive went from OpenConfirm to Established
*Jul 10 08:01:54.931: BGP: ses global 192.168.23.3 (0x10E57368:1) pas Assigned ID
*Jul 10 08:01:54.931: BGP: nbr global 192.168.23.3 Stop Active Open timer as all topologies are allocated
*Jul 10 08:01:54.933: BGP: ses global 192.168.23.3 (0x10E57368:1) Up
*Jul 10 08:01:54.933: %BGP-5-ADJCHANGE: neighbor 192.168.23.3 Up
*Jul 10 08:01:54.953: BGP_Router: unhandled major event code 128, minor 0

Just as the concepts of stub and transit (core) autonomous systems were introduced in EGP, that pioneering protocol also introduced the concepts of interior and exterior neighbors. That is, if an EGP process peers with a neighbor in the same AS, the neighbor is interior; if the neighbor is in a different AS, the neighbor is exterior.

BGP uses the same concept: If a BGP session is established between two neighbors in different autonomous systems, the session is external BGP (EBGP), and if the session is established between two neighbors in the same AS, the session is internal BGP (IBGP).
Multiple routers usually exist within an AS, so IBGP is necessary whenever BGP advertised information must be passed within a given AS. , For instance, the combination of EBGP and IBGP sessions makes it possible for the router in AS1 to advertise a route to the router in AS3. Traditionally, IBGP is associated with transit autonomous systems such as AS2 . A stub AS usually runs EBGP at one or more edge routers only, and routes packets to and from the edge routers via an IGP. However, with multiprotocol BGP being used more and more frequently for services, such as MPLS-based VPNs and IP multicast, IBGP is beginning to appear even in stub autonomous systems.

Recall that BGP routers use the AS_PATH not only as an AS hop count metric but also as a loop avoidance device: If a router sees its own AS number on the AS_PATH list, it drops the route. This presents some interesting problems for IBGP.

Consider, for example, a route being communicated from AS1 to AS3, through AS2. The physical path across AS2 is through three routers, RTR1, RTR2, and RTR3. If each of these three routers adds its AS number to the AS_PATH list as it passes the route along, two problems arise:

■ The AS_PATH list no longer is a true representation of the length of the inter-AS path. AS2 is a single AS hop and should be represented by one entry on the AS_PATH list. If each router makes an entry for AS2, the AS number would appear three times (Figure 1-8).

■ The loop avoidance function of the AS_PATH stipulates that if a router sees its own AS number on the AS_PATH list, it assumes a loop has occurred and drops the route. So if RTR1 added AS number 2 to the list, RTR2, seeing that AS number and knowing it is in AS2, would drop the route.
The solution to these problems is a special rule for IBGP: A router adds its AS number to a route’s AS_PATH only when the route is sent to an EBGP neighbor. The AS number is not added to routes sent to an IBGP neighbor.

Figure 1-10 shows the effects of this rule: Routers within AS2 do not drop the route because they do not see their own AS number on the AS_PATH list, and the router in AS3 correctly determines the AS hop distance to prefix A.

This rule solves the problems represented in Figures 1-8 and 1-9 but introduces another problem. Detecting one’s AS number on the AS_PATH list is BGP’s method of detecting and avoiding routing loops; however, the AS_PATH is meaningless within the scope of a single AS. What if a routing loop does exist within the AS? How can you avoid it?

To answer this problem you must look again to EGP. That protocol had no loop avoidance mechanism, so the solution was to ensure a loop-free topology. This is also the rationale behind hierarchical area topologies in OSPF and IS-IS, as discussed in Volume I; SPF trees (the means by which link-state protocols “see” loops) do not span area boundaries, so a loop-free inter-area topology is imposed.

This, then, is also the solution to the IBGP routing loop vulnerability: Ensure that the IBGP peering sessions cannot loop by requiring a loop-free topology. One of the keys to this solution is that BGP sessions run over TCP, which is unicast point-to-point (avoiding at least some looping risks) and has no requirement that the two points of the session physically connect. So in the example network, even though the path through AS2 transits three routers, the IBGP session can be established directly between the edge routers, as shown in Figure 1-11. The IBGP session is following the physical path through RTR2 but logically exists only between RTR1 and RTR3.

iBGP are BGP peers that are sharing the same AS (autonomous system) e.g ASN 100, direct peering are required in order to exchange prefixes, on the other hand  eBGP is categorized as BGP peering that are connected to other AS.

For example  a company connecting to an internet provider requires an External Peering as they will be exchanging prefixes between different AS.

Client AS 100 peering with ISP AS 2000

 

Hope this short explanation provides additional clarification.

 

P.Williams

The original poster asked a beginning question and then refined the question as follows "At what stage during BGP neighbor ship establishment does it need to make iBGP/eBGP". There have been several responses that addressed the questions and I would like to approach it from a slightly different perspective.

When you configure BGP on the router you specify what AS number this router will use. And when you configure a neighbor for BGP you specify what AS number that router will use. So when this router prepares to begin negotiation with the neighbor it compares the two AS numbers. If the neighbor uses the same AS number as this router then the BGP session needs to be IBGP. And if the neighbor uses a different AS number then the BGP session needs to be EBGP. So as this router prepares to begin the neighbor negotiation it determines whether it will be negotiating for IBGP or EBGP.

 

HTH

 

Rick

HTH

Rick
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: