Internal BGP (Border Gateway Protocol) explained

(samit k) #116

Hi Rene
I did not get your this phrase “you are forced to use physical interfaces” could you please rephrase it for me

(samit k) #117

Hi Rene
why do we need to use physical interfaces as lo interface can work well.

(samit k) #118

hi Rene

i am still not clear with your explanation.

(Lazaros Agapides) #119

Hello Brian

When you ping from R1 to R3, you will use a source address of 192.168.1.1 and a destination address of 3.3.3.3. When you ping from R3 to R1, the source address used of R3 for the ping will by default be the IP address of the interface through which the ping will be routed. In this case, the source address will not be 3.3.3.3 but 192.168.23.3. Now if you look in the routing table of R1, you will see that the 192.168.23.0/24 subnet is not there. Therefore R1 will receive the echo request successfully but it doesn’t know how to send it back to the source IP because it has no route to 192.168.23.0/24.

Now if you try an extended ping from R3 to R1 using the source address of 3.3.3.3, then the ping should be answered because as you correctly described, the 3.3.3.0 subnet is indeed in R1’s routing table.

I hope this has been helpful!

Laz

(Lazaros Agapides) #120

Hello Samit

The original question was “can we do away with OSPF and use loopback addresses for BGP peering by advertising the loobacks of each BGP router”

Rene’s answer was one of the reasons why this is not possible. Without OSPF, the loopbacks cannot be advertised to all of the BGP routers within the AS because of the fact that any such advertisements would not reach all of the required routers due to the iBGP split horizon rule. So, if you want to avoid using OSPF, you will be required to have a physical connection between routers R2 and R4 and to use the physical interface IP addresses for BGP peering. This will allow iBGP to be implemented without OSPF or some other IGP.

I hope this has been helpful!

Laz

(Brian C) #121

actually it is helpful. I have ran into that in the work place. I just was so focused I was not seeing it. I have actually ran into that in the work environment. where we had a bgp prefix of a customer and we needed to test to see if they could get outside the ISP network. My initial pings did not work because of something similar here where the IP being used by default by the ping was not the correct one and we had to use the source command. So that is vey similar to this except in those cases it was actual public IPs and not loopbacks. However, now that you have pointed it out and its allowed me to step back and see from a further out it makes perfect sense.

Thanks!

1 Like
(Vinod A) #122

Hi Rane, Thanks for explaination . Is it good idea to change next-hop at each ibgp router /speaker . what is other option that can we use.

(Lazaros Agapides) #123

Hello Vinod

If there is no next hop, we can’t install the prefix from BGP into the routing table. So in order to fix this, we can either change the next hop IP address with the next-hop-self command or we can advertise the network in question using a routing protocol, either an IGP or via BGP so that the network will be in the routing table and the prefix will be installed in the routing table from BGP.

I hope this has been helpful!

Laz

(Gareth W) #124

Why does eBGP have a lower admin distance than iBGP? Surely if a route is available from within the internal network then that should be used?

(Lazaros Agapides) #125

Hello Gareth

By default, eBGP has an AD of 20 while iBGP has an AD of 200, and all IGRPs are somewhere between. This is done on purpose. If you learn of a route to a destination via eBGP, that means that that destination does not exist in your AS, but it was learned from another AS. If for whatever reason the same destination is advertised by any other routing protocol (IGRP or iBGP for example), the eBGP should take precedence, because if you want to reach that destination, you will definitely what it to be routed via eBGP to the external AS and not via your own network. This is because eventually, you will have to exit your network again (from the same or a different point) to get to that destination because by definition it is not in your AS.

Now if you learn of a destination via iBGP, you know that the destination is in your AS. But, if that same destination is advertised by an IGRP such as OSPF or EIGRP, then you would prefer to use those routing protocols to get there, because they converge faster and they are more appropriate for routing internally. This is why iBGP has a higher AD than the IGRPs. iBGP will only be used if the destination is not advertised in any other way.

So in short, eBGP should be preferred to any IGRPs for any destination learned via eBGP, because such a destination is in a different AS, therefore even if another routing protocol advertises the same destination, it is preferable to go directly via eBGP outside of your AS.

iBGP should always be the last choice because such a destination is in the same AS and if you have the same destination advertised via an IGRP, it is preferable to use that.

I hope this has been helpful!

Laz

(Gareth W) #126

Thanks Laz.

So if I had 195.50.1.1 /32 within my network and another ISP started to advertise it to me accidentally via eBGP, then this route would be used and cause me problems within my network?

I appreciate that you would have routing policies to prevent this but in theory, this is what would happen?

Thanks,

Gareth.

(Lazaros Agapides) #127

Hello Gareth

Let’s assume you have two independent ISP connections from two different telcos. You are advertising the 195.50.1.1 /32 address, which is an internal address for you, via BGP to ISP1. ISP 2 has learned of a route to 195.50.1.1 /32 via BGP on the Internet. This ISP is advertising this IP address to you and telling your network that any packets destined for this address should be sent via this second ISP.

This would indeed cause you problems as you mention in your post. However, in such situations it is your responsibility to verify that you appropriately filter all routes such that no internal public IPs will be learned from external sources such as an alternate ISP. This is typically best practice in order to avoid the kinds of problems you describe.

Remember that the default parameters set up on protocols such as BGP are designed to accommodate the most common implementations. Protocols have an abundance of parameters that can be manipulated to get the desired behaviour for almost all situations. BGP is one of the most “parameterized” protocols and can be configured to deal with virtually all enterprise needs.

I hope this has been helpful!

Laz

(Arif J) #128

anyone explain… can routers on different subnets become BGP neighbors? Explain why or why not.

(Andy K) #130

Great explanation, especially on why R3 needed to run iBGP as well. That had me stumped until I read your explanation. Keep up with good work.

1 Like
(Ankit M) #131

Hi Rene,

You said in this post that for non-directly connected iBGP neighbour TTL value is higher but as i understood , iBGP neighbours should be full mesh. Then in which scenario we would have indirect iBGP neighbours?

Also i need to ask that if two router R1 and R2 are iBGP neighbour, how does R2 allows the prefix from R1 ( as both are in same AS). Shouldn’t be as per BGP split horizon rule, R2 when receives its on AS number in learned prefix, should reject the route from R1??

Pls help to clarify.

(Lazaros Agapides) #132

Hello Ankit

When Rene refers to full mesh, he is referring only to the BGP neighbor adjacencies and not the physical topology. You can have several routers in a sing AS where they are not fully meshed physically, but are fully meshed as far as the neighbor adjacenceis go. Remember that unlike Interior Gateway routing protocols, BGP neighbor adjacencies can be formed between neighbors that are not directly connected.

Concerning your second question, the split horizon rule states that any ROUTE (not AS) that is learned from an iBGP neighbor is not shared with any other iBGP neighbors. If R2 receives a route from R1, it can safely receive it without a problem, the split horizon rule does not prevent that, even if it is in the same AS. R2 however will not share this route with any other iBGP peers. Note that split horizon will not prevent a router from accepting a sent route, but will prevent a router from sending it in the first place (if the split horizon conditions are met).

I hope this has been helpful!

Laz

(sims) #133

Hi,

R1–e0/0-----------e0/0 --R2 , iBGP configured but sh ip bgp shows nothing ?
Any help

configurations are below

R1 

interface Loopback0
 ip address 1.1.1.1 255.255.255.0
!
interface Ethernet0/0
 ip address 192.168.1.1 255.255.255.0
!

router ospf 1
 network 1.1.1.0 0.0.0.255 area 0
 network 192.168.1.0 0.0.0.255 area 0
!
router bgp 100
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 100


!


R2 
interface Loopback0
 ip address 2.2.2.2 255.255.255.0
!
interface Ethernet0/0
 ip address 192.168.1.2 255.255.255.0


router ospf 1
 network 2.2.2.0 0.0.0.0 area 0
 network 192.168.1.0 0.0.0.255 area 0
!


router bgp 100
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 100



R2#sh ip bgp 
R2#
R2#
(Lazaros Agapides) #134

Hello sims

Try issuing the show ip bgp summary. You should see that the routers are indeed becoming neighbors. However, you are not advertising any routes between the routers using BGP, so the show ip bgp command shows nothing. Add some routes using the network command under the bgp configuration of each router. For example:

R1
router bgp 100
  network 1.1.1.0 255.255.255.0
  
R2
router bgp 100
  network 2.2.2.0 255.255.255.0

I hope this has been helpful!

Laz

(sims) #135

Added on R1
network 1.1.1.0 mask 255.255.255.0
and R2 shows that it did not learn any prefixes

R2#sh ip bgp summary 
BGP router identifier 2.2.2.2, local AS number 100
BGP table version is 2, main routing table version 2
1 network entries using 144 bytes of memory
1 path entries using 80 bytes of memory
1/1 BGP path/bestpath attribute entries using 152 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 376 total bytes of memory
BGP activity 1/0 prefixes, 1/0 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4          100       0       0        1    0    0 never    Idle
R2#
R2#sh ip route       
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
O        1.1.1.1 [110/11] via 192.168.1.1, 01:35:19, Ethernet0/0
      2.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        2.2.2.0/24 is directly connected, Loopback0
L        2.2.2.2/32 is directly connected, Loopback0
      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/24 is directly connected, Ethernet0/0
L        192.168.1.2/32 is directly connected, Ethernet0/0

Thanks

(Lazaros Agapides) #136

Hello again Sims

I’m not sure if your configuration is set up this way or not, but there is a slight error on the configuration, something I missed before. In R2, you have the following under the OSPF configuration:

network 2.2.2.0 0.0.0.0 area 0

It should be

network 2.2.2.0 0.0.0.255 area 0

This would make 2.2.2.2 unreachable from R1, causing R1 not to see a BGP neighbor and consequently not being able to receive any networks from R2. Once you correct this, verify that OSPF is working correctly and that one loopback can ping the other. This should bring up the BGP adjacency. Now in your above output, you can see that R2 can see R1 as its BGP neighbor. This is the case even through R1 cannot see R2 as its neighbor because of the error in the OSPF config.

I hope this has been helpful!

Laz