When BGP is comming up the interfaces are flapping, you still have the chance that only one of the BGP sessions won't be able to be established. To minimize this, configure the neighbor with the update-source command when
possible. So, you can have one interface in each side (each primary+secondary address, two peerings); or any number of interfaces (peering only with primary addresses).
Troubleshooting BGP neighbors:
I am not sure that I ever really tested this so I do not have an authoritative answer. But I believe that there is a problem with attempting to do BGP peering with a secondary address. The problem is that when the router builds a TCP packet for BGP it will use as the source address the primary address of the interface. There is not any way that I know to change this behavior and there certainly is not an option on the update-source command to specify to use the secondary address. So the peer router will receive a TCP BGP packet and the source address will not be the configured peer address. In this case I believe that the router drops the packet.
Is there a particular reason to want to peer from the secondary address? Perhaps if we knew more about the situation and the requirements we might be able to suggest an alternative that could work.
If this is an iBGP session, then I expect no issues, since neighbors do not even have to be in the same subnet.
Same way for the multihop eBGP case (secondary won't even be noticed).
If this is eBGP and the peers are directly connected, then again they should have an IP address in a common subnet and I believe this should suffice for them to reach each other and start a basic TCP session for BGP.
Have never actually tried this (have heard only about OSPF limitations with secondaries, not BGP). Please tell us about the outcome.
p.s. Now that I think about it more, the only case that might be problematic is the case of eBGP, but I suspect that even this can be resolved with the multihop eBGP hack.
First, any specific reason to do that?
It will work if the two routers are on a common subnet as they will see that the neighbor is part of a subnet that is configured as a secondary subnet and automatically use this address as the source of the TCP session.
Thank you all for your answers and i am sorry for my late answer.
What we want to do is :
We want to advertise 3 different ASs from our router. We wanted to do that using 3 different loopbacks , but unfortunately our upstream provider told us that they do not use this configuration template, so therefore as an alternative solution they proposed the use of primary and secondary IPs.
I already found a cisco bug : CSCeb48064 that is related to primary and secondary IP addresses.
C2MSFC3 : BGP Peer not formed with secondary address configured
If a router uses a secondary address as neighbor address the session will
not be accepted
Use a primary (or loopback) address for the session.
As this is not an acceptable technique for our upstream provider (the use of loopbacks) I asked you if you are aware of any additional problems that might occur using this configuration.
There are some things in your explanation that I do not understand. In particular when you say:
"We want to advertise 3 different ASs from our router. We wanted to do that using 3 different loopbacks"
Do you really mean 3 different ASes? Or perhaps was it 3 different networks? I do not understand how using a secondary address would change how many ASes you advertise. Can you help us understand better?
I am really sorry for my delayed answer.
I mean 3 different ASs. It does not change how many ASs I can advertise you are right.
My client wants the specific implementation so I asked you if you are aware of any problems that might occur by doint this.
I hope I explained it better
I do not understand what the "3 different loopback" configuration is and what is the purpose of it. OTEnet is an ISP in Greece. As far as I know it is common for ISPs to say that they "advertise an AS" and actually mean "provide transit for the AS" (i.e. BGP client advertises its own networks with its own originating AS number towards the ISP and ISP "forwards" those advertisements to the rest of the world). Is that what you mean Georgia or something else ? I am thinking that maybe you intended to establish 3 different eBGP multihop sessions with the peer ISP using the 3 loopbacks, but can't understand the actual reason for such a setup. Is this some service for clients or something else? If you clarify the setup and its purpose, it would be easier for us to think about possible issues and possible alternatives.