pracując z wieloma konfiguracjami (oraz - nieuchronnie - rozwiązywaniem problemów), możesz trafić czasem na sytuacje w których masz ograniczoną widoczność “drugiej strony” (“hej, to urządzenie klienta!”). nie masz możliwości “wykonać paru poleceń” czy “sprawdzić jednej rzeczy”.
i tu trafia nam się dokładnie taki przypadek - “macie włączoną obsługę wielu protokołów i mi to nie działa”
mp-bgp? tu nie ma żadnego mp-bgp!
mój przyjaciel poprosił mnie o pomoc - jego Klient nie mógł zestawić sesji BGP i co więcej, zaczął twierdzić, że “wysyłacie mi jakieś rozszerzone capabilities”. do narzekania załączony został “przykładowy log” razem z “życzliwymi” rekomendacjami jak przekonfigurować urządzenie przyjaciela (operatorskie).
*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
w istocie dziwne. wygląda jakbyśmy faktycznie nie wysyłali w ogóle BGP AFI/SAFI 1/2 - znanego też pod nazwą “stary dobry unicast IPv4” (czyli tak naprawdę bardziej ang. address family - rodziny protokołów, niż ang. capability). pełną listę AFI znaleźć można tutaj, a SAFI tutaj. poprosiłem o dosłanie konfiguracji i dostałem tą od strony operatora (czyli przyjaciela):
!
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
!
!
no cóż, cytując klasyka (w tym przypadku z filmu Pi) - “gdy wystarczająco długo patrzysz w logi, zaczynasz dostrzegać wzorce”… konfiguracja jest w porządku, ponieważ mimo deklaracji VRFu, router odpowiedzialny jest za przetłumaczenie otrzymywanych prefiksów z IPv4 unicast na VPNv4 unicast i odwrotnie dla sąsiada 172.16.0.21. nie tu leży problem. jakie polecenie powinno się w tym momencie wydać żeby zweryfikować w czym rzecz?
wielka prawda zostaje objawiona
no cóż, jest to polecenie 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)
klient wysyła po prostu za dużo prefiksów, dochodząc do limitu zdefioniowanego w maximum-prefix i sesja zostaje położona. jeśli spojrzymy w pełen log z sesji, na jego początku znajdzie się coś w stylu:
*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
…a potem już w pętli:
*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
dlaczego w pętli? ponieważ domyślna konfiguracja polecenia maximum-prefix dokładnie tak działa - do czasu manualnego wyczyszczenia sesji, nie pozwoli jej się podnieść (można to zachowanie zmodyfikować, dodając różne parametry)
co ciekawe, sprawdziłem zachowanie dla IOS XR - nie wysyła on dodatkowego komunikatu BGP NOTIFICATION z nieco mylącym komunikatem no supported AFI/SAFI. po stronie odbierającego, tak zablokowana sesja wygląda w ten sposób:
*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 i FTD dziedziczą kod routingu od IOS-XE, a zatem ich zachowanie jest identyczne (wysyłają w pętli BGP NOTIFICATION do sąsiada).
jeśli dysponujesz fragmentem logu i to tylko od strony naruszającej limit prefiksów, trudno się zorientować co jest nie tak. bardzo łatwo też można wyciągnąć błędne wnioski.
podsumowanie
bezpieczeństwo ma swoją cenę. w związku z tym o ile ten przykład jest trywialny do zdiagnozowania (jeśli znajdujesz się po stronie ustawiającej limit) warto zagłębiać się w takie przypadki żeby zdobyć doświadczenie.