cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1606
Views
0
Helpful
4
Replies

BGP update-source vs neighbor ip

CriscoSystems
Level 5
Level 5

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

4 Replies 4

kankung
Level 1
Level 1

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
Cisco Employee
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

"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
Hall of Fame
Hall of Fame

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

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco