Hello Shashidhar
I went in and labbed this up for myself and I got the same results as you. Digging a little deeper, it seems that what you and I experienced is normal behaviour
.
I did a debug on BGP updates on R2 (debug ip bgp updates
) and then cleared the BGP peering (clear ip bgp *
). The resulting syslog message I get is:
*Mar 27 06:03:59.624: BGP(0): Can't advertise 2.2.2.2/32 to FD00:0:0:1000::1 with NEXT_HOP 253.0.0.0
In my case, my loopback address on R2 is 2.2.2.2. From the above you can see that it can’t advertise this address because it has problems determining the next hop IP address to share with its BGP neighbor.
Now what it’s trying to do is encode the next hop IP address, but it is failing, because the next hop IP address is IPv6. Ideally, the next hop address should be of the same type as the prefix. In this case, the next hop IP should be the IPv4 address of the interface on R2, but it’s not working. Why? Simply because IOS doesn’t support it. ![:face_with_raised_eyebrow: :face_with_raised_eyebrow:](https://cdn-forum.networklessons.com/images/emoji/apple/face_with_raised_eyebrow.png?v=12)
Digging deeper (and with help from @ReneMolenaar), I have found that some operating systems support the encoding of a different version IP address, and some don’t. In this case Cisco IOS doesn’t support this, but Nexus NX-OS does.
Furthermore, this is described in RFC 5549 where it states that:
By default, if a particular BGP session is running over IPvx (where
IPvx is IPv4 or IPv6), and if the BGP speaker sending an update is
putting its own address in as the next hop, then the next hop address
SHOULD be specified as an IPvx address, using the encoding rules
specified in the AFI/SAFI definition of the NLRI being updated. This
default behavior may be overridden by policy.
When a next hop address needs to be passed along unchanged (e.g., as
a Route Reflector (RR) would do), its encoding MUST NOT be changed.
If a particular RR client cannot handle that encoding (as determined
by the BGP Capability Advertisement), then the NLRI in question
cannot be distributed to that client. For sound routing in certain
scenarios, this will require that all the RR clients be able to
handle whatever encodings any of them may generate.
Now we’re not using an RR in this case, but the concept is the same.
One of the things I really like about this forum is that it is an opportunity for me to learn. I love digging deeper to understand why things are the way they are. Thanks for giving me another opportunity to do that!!
I hope this has been helpful!
Laz