BGP update-source vs neighbor ip

Unanswered Question
Oct 28th, 2009
User Badges:
  • Bronze, 100 points or more

This is one of those "I'm not really sure what I'm asking" type questions.


FINALLY, I found a decent explanation of the BGP update-source command and its usefulness: Neighbors mightn't be directly connected, and therefore there can be alternative paths through the AS to the same neighbor, but arriving on a different interface.


The update-source command also lets you name a loopback address as the update-source (as long as the address is routable through the AS); and apparently, this is the way to go; a loopback interface will never go down.


So...and here's where the not-sure-what-I'm-asking part comes into play...why bother with separate commands here? Why not just set up a loopback address on the routers you want to run BGP and use that address in the neighbor...remote-as command?


Does it make a whole bunch of sense to give an IP address in the neighbor statement, when _all_ of that address's uses are going to be performed instead by a different, update-source address?


I welcome your answers.


Or your interpretation of what my question is.


I'm tired.


Zzzzzzz

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
kankung Wed, 10/28/2009 - 20:20
User Badges:

I think it depends on the situation. If you manage all BGP routers and they have multiple path to reach each others, loopback will be a good one as an update source and to build neighbour.


We have a managed CE router which connected to AT&T PE router, for this case, I am using serial interface's IP in CE to build BGP with AT&T PE, I prefer not use loopback in this case.

Peter Paluch Thu, 10/29/2009 - 02:52
User Badges:
  • Cisco Employee,

Hi Seth,


I don't know if I'm tackling your point but if you are asking why the loopback addresses aren't used in the "neighbor" commands all the time, consider these facts.


In iBGP, inside an autonomous system, the BGP speakers are not expected all to be directly connected. Thus, you can configure an iBGP neighbor by specifying any of his existing IP addresses that is reachable. However, when you - as a router - decide which interface will your BGP packet go out to reach that neighbor, that interface will be put into the packet's source IP address field. Now consider the fact that your interfaces may go up or down or the routing protocol information may change so during an iBGP session, it may happen that you start sending your BGP packets to a particular peer from another outgoing interface than you originally used to establish the BGP session. This would create peering problems, as the peering is bound to IP addresses of the neighbors, and if they change, the peering session will have to be reestablished from the scratch. The loopbacks here are helping you here to maintain a stable pair of communicating IP addresses that do not depend on the state of actual physical interfaces or existing routes through an internetwork. Of course, the loopbacks must be reachable, i.e., the path to them must actually exist.


However, the BGP cannot know if you actually wish to peer your iBGP neighbor with a loopback address or just with the address of your physical interface that is used to reach that neighbor. Your network topology may be so simple that you have only one interface that goes towards your iBGP neighbor so in that case, requiring you to configure and advertise a loopback would simply be a formal and useless burden.


Moreover, for eBGP peers between two different autonomous systems, the Cisco implementation requires that the peers are directly connected, otherwise the peering won't come up. Note that even if two directly connected eBGP peers mutually knew their loopback addresses, these loopbacks are not on common network segment (they're not "directly connected" one to the other) and the eBGP peering would not be created.


So all this reasoning brings us to the idea that you should be able to use a loopback address as your IP source address when talking to a peer if you so wish but you absolutely should not be forced to use it. This freedom of choice necessarily brings the special "neighbor update-source" command.


Note that the "neighbor update-source" has a profound impact on the NEXT_HOP BGP attribute, as it will be the very content of the NEXT_HOP when a network is introduced into BGP or advertised from another AS. So it's not just playing with source and destination in IP packet header that carries the BGP session, it is also influencing the NEXT_HOP attribute value.


Best regards,

Peter


CriscoSystems Thu, 10/29/2009 - 11:16
User Badges:
  • Bronze, 100 points or more

"decide which interface will your BGP packet go out to reach that neighbor, that interface will be put into the packet's source IP address field"


I thought the whole point of the update-source command was that the outgoing interface's IP address WON'T be the source address; that it will have been replaced by the address of the interface specified in update-source.


Giuseppe Larosa Thu, 10/29/2009 - 10:26
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Stuey,


practical point of view:

neigh x.x.x.x remote-as ASN


here x.x.x.x is the intended destination of the BGP session

in

neigh x.x.x.x update-source loopM

we add that the BGP session will use

IP SA = loopM; IP Destination= x.x.x.x


if we don't specify the update-source the source will be that of outgoing interface to x.x.x.x as in the IP routing table on local-node.


This could cause a problem on the neighbor that is expecting messages with source= loopM.


You can see a BGP session as a user traffic flow that uses routing services to be setup and mantained.


For example in an MPLS environment, iBGP packets are placed within the LSP with destination = x.x.x.x!


We have faculty to specify the IP addresses in the socket as:

TCP x.x.x.x:179 --- m.m.m.m:yyy


or it will be

TCP x.x.x.x:yyy --- m.m.m.m:179


the well-known port will be on a specific side depending on some parameters.



>> Does it make a whole bunch of sense to give an IP address in the neighbor statement, when _all_ of that address's uses are going to be performed instead by a different, update-source address?


yes because one is the destination and one is the source of the BGP TCP socket as explained above.


There are also other technical effects that are well explained by Peter.


Hope to help

Giuseppe


Actions

This Discussion