as you work through various configurations (and - envitably - troubleshooting), you may end up in situation where because of limited visibility (“hey, it’s customer device!”) you can’t really see what’s wrong on the other side.
here’s one example - of (allegedly) “Multi-Protocol BGP being enabled”
mp-bgp? ain’t no mp-bgp!
my friend asked me for help - his Customer can’t make BGP session work and complains about “additional capabilities” we’re sending his way. before looking at friends config, I’m looking at the logs he got from complaining customer:
*Jun 11 23:50:45.052: %BGP_SESSION-5-ADJCHANGE: neighbor 172.16.0.11 IPv4 Unicast topology base removed from session Peer closed the session
*Jun 19 23:50:58.071: %BGP-3-NOTIFICATION: received from neighbor 172.16.0.11 active 2/8 (no supported AFI/SAFI) 3 bytes 000000
*Jun 19 23:50:58.071: %BGP-5-NBR_RESET: Neighbor 172.16.0.11 active reset (BGP Notification received)
*Jun 19 23:50:58.073: %BGP-5-ADJCHANGE: neighbor 172.16.0.11 active Down BGP Notification received
*Jun 19 23:50:58.074: %BGP_SESSION-5-ADJCHANGE: neighbor 172.16.0.11 IPv4 Unicast topology base removed from session BGP Notification received
that’s weird. indeed it looks like we’re not really sending any IPv4 unicast (BGP AFI/SAFI 1/2- you can review full list here for address families, and here for subsequent address families). I asked my friend for his config, just to cross-check what’s going on and he sends me something to the effect of:
!
router bgp 64510
!
address-family ipv4 vrf VIP-CUSTOMER-4
neighbor 172.16.0.21 remote-as 64909
neighbor 172.16.0.21 activate
neighbor 172.16.0.21 maximum-prefix 100
!
!
well, if you look at logs long enough, patterns start to emerge (quote from Pi movie)… config looks absolutely fine, and should attempt to open BGP session “translated” on the fly by router from VPNv4 unicast back to IPv4 unicast for 172.16.0.21. which command should you request to run in such case to validate your finding - if you obviously know what’s wrong?
big reveal
well, it’s show bgp vpnv4 unicast vrf VIP-CUSTOMER-4 summary:
R11#show bgp vpnv4 unicast vrf VIP-CUSTOMER-4 summary
[...]
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.16.0.21 4 21 31 26 17 0 0 00:05:21 Idle (PfxCt)
customer is sending too many prefixes, triggering maximum-prefix limit, and session goes down. if you’d get full troubleshooting log, at the beginning of it, you’d see something like:
*Jun 11 23:50:45.047: %BGP-3-NOTIFICATION: received from neighbor 172.16.0.11 6/1 (Maximum Number of Prefixes Reached) 7 bytes 00018000 000002
*Jun 11 23:50:45.052: %BGP-5-ADJCHANGE: neighbor 172.16.0.11 Down Peer closed the session
…and then, repeated in loop:
*Jun 11 23:50:45.052: %BGP_SESSION-5-ADJCHANGE: neighbor 172.16.0.11 IPv4 Unicast topology base removed from session Peer closed the session
*Jun 11 23:50:58.071: %BGP-3-NOTIFICATION: received from neighbor 172.16.0.11 active 2/8 (no supported AFI/SAFI) 3 bytes 000000
*Jun 11 23:50:58.071: %BGP-5-NBR_RESET: Neighbor 172.16.0.11 active reset (BGP Notification received)
*Jun 11 23:50:58.073: %BGP-5-ADJCHANGE: neighbor 172.16.0.11 active Down BGP Notification received
why in loop? because that’s default behavior of maximum-prefix feature - until you manually clear the session, the session won’t be brought back (you can change that behavior by adding arguments).
interestingly enough, IOS XR doesn’t send the BGP NOTIFICATION with no supported AFI/SAFI to avoid creating confusion. the same logging from device on “receiving end” of maximum-prefix limit on IOS XR device:
*Jun 11 00:28:09.551: %BGP-3-NOTIFICATION: received from neighbor 172.16.0.31 6/1 (Maximum Number of Prefixes Reached) 6 bytes 01010000 0003
*Jun 11 00:28:09.553: %BGP-5-ADJCHANGE: neighbor 172.16.0.31 Down Peer closed the session
*Jun 11 00:28:09.553: %BGP_SESSION-5-ADJCHANGE: neighbor 172.16.0.31 IPv4 Unicast topology base removed from session Peer closed the session
*Jun 11 00:28:15.868: %BGP-5-NBR_RESET: Neighbor 172.16.0.31 active reset (Peer closed the session)
*Jun 11 00:28:15.868: %BGP_SESSION-5-ADJCHANGE: neighbor 172.16.0.31 IPv4 Unicast topology base removed from session Peer closed the session
*Jun 11 00:28:27.143: %BGP-5-NBR_RESET: Neighbor 172.16.0.31 active reset (Peer closed the session)
*Jun 11 00:28:27.144: %BGP_SESSION-5-ADJCHANGE: neighbor 172.16.0.31 IPv4 Unicast topology base removed from session Peer closed the session
*Jun 11 00:28:40.078: %BGP-5-NBR_RESET: Neighbor 172.16.0.31 active reset (Peer closed the session)
*Jun 11 00:28:40.080: %BGP_SESSION-5-ADJCHANGE: neighbor 172.16.0.31 IPv4 Unicast topology base removed from session Peer closed the session
Cisco ASA and FTD inherit routing code base from IOS-XE, and therefore their behavior is identical (they send BGP NOTIFICATION to neighbor in loop).
on receiving end, initial cause is easy to overlook. if you’re on receiving end (as a Customer), you may quickly draw wrong conclusions.
summary
security comes typically at price - and therefore, while this case was trivial to troubleshoot (if you have access to Service Provider router), sometimes the behavior or partial log output may be misleading. it’s worth to dig into such cases to gather more operational experience.