Ci z Was, którzy pracują z konfiguracją i rekonfiguracją ciągle trafiają na różnego rodzaju ciekawostki ale i problemy, które następnie kosztują godziny.

trasa? jaka trasa?

dzień jak co dzień - podłączamy nowy router. router ma adres 172.16.0.11 przypisany do interfejsu Loopback0 (a jakże). interfejs, podobnie jak jego fizyczne włączony jest do procesu OSPF w obszarze 0. tak widzą go też sąsiedzi:

RP/0/RSP0/CPU0:XR-RTR#sh route 172.16.0.11

Routing entry for 172.16.0.11/32
  Known via "ospf 0", distance 110, metric 3, type intra area
  Routing Descriptor Blocks
    10.128.0.20, from 172.16.0.11, via FortyGigE0/0/1/0.172
      Route metric is 3
  No advertising protos.

wszystko OK, ale usługi z tego interfejsu (między innymi BGP i LDP) nie działaja. nie działają bo… adres jest nieosiągalny:

RP/0/RSP0/CPU0:XR-RTR#ping 172.16.0.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.11, timeout is 2 seconds:
.....

RP/0/RSP0/CPU0:XR-RTR#ping 172.16.0.11 source 172.16.0.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.11, timeout is 2 seconds:
.....

to dziwne, ponieważ jest to adres widoczny przez bezpośrednio podłączony interfejs FortyGigE0/0/1/0.172, który jest w stanie up i komunikacja pomiędzy adresami na interfejsie działa bez problemu:

RP/0/RSP0/CPU0:XR-RTR#sh run int FortyGigE0/0/1/0.172
interface FortyGigE0/0/1/0.172
 ipv4 address 10.128.0.21 255.255.255.254

sprawa wydaje się abstrakcyjna - routery są ze sobą bezpośrednio połączone, wszystko inne działa a nowa usługa (i de facto nowy router) - nie. co tu robić?

w tym momencie ważną przesłanką daje wykonanie zrzutu ruchu po stronie nowego routera (ang. packet capture). tajemnica staje się bardziej oczywista, gdy okazuje się że nie widać żadnego ruchu do adresu przydzielonego do interfejsu Loopback0!

duchy?

skoro zaglądanie do tablicy routingu nie daje rezultatów, pozostaje zagłębić się w trzewia IOS XR i sposobu w jaki konstruuje on tablicę forwardingu (ang. FIB). zajrzyjmy zatem najpierw do tablicy CEF:

RP/0/RSP0/CPU0:XR-RTR#sh cef 172.16.0.11 detail
172.16.0.11/32, version 0, broadcast
  Updated Nov 29 22:26:16.968
  Prefix Len 32

dziwne. konfiguracja jest świeża (kwiecień), a wpis trafił do tablicy CEF już w listopadzie zeszłego roku? jak to możliwe? sprawdźmy dokładniej:

RP/0/RSP0/CPU0:XR-RTR#sh cef 172.16.0.11 internal

IPv4:default:0xe0000000[0x9d4a3294]:interface:172.16.0.11/32[ref:1 proto:ipv4 flags:0x1010001 f2:0x0 src:interface][0xa4470724]
  LDI:[ref:2 pl:a70d2e5c proto:ipv4 type:ip lvl:1 buckets:1 slots:1 fixup:0 flags:[owner locked, added to pl, depth changed]][0x9de44a10]
    slots:
    {0,p0,s0}={
      nhinfo:[type:special, linkt:link_IPv4, nh_proto:IPv4, ifh:NULLIFHNDL, spl:broadcast, flags:[owner locked, special]][0x9d3db180]
    }
    buckets:
    {0,p0,s0}={[0x9d3db180]}
  LDI_LW:[type:ip loadinfo:[0x9de44a10]][0x9dee81a8]
  PATHLIST:[ref:1 count:1 depth:1 ldi:9de44a10 type:Unspecified flags:[]][0xa70d2e5c]
    0={
      [[nh:0.0.0.0 ifh:TenGigE0_0_2_3(0x4000780) tbl:0xe0000000 type:ip flags:[none]]
      [depth:1 flags:[resolved,ldi-preferred] resolves-via: ###
        nhinfo:[type:special, linkt:link_IPv4, nh_proto:IPv4, ifh:NULLIFHNDL, spl:broadcast, flags:[owner locked, special]][0x9d3db180]
    ###]}

…wszystko wygląda na bardzo skomplikowane, ale zawiera rozwiązanie zagadki. obecnie CEF uważa bowiem, że trasę należy zaprogramować przez interfejs TenGigE0/0/2/3. jak to możliwe? zobaczmy co się dzieje na tym interfejsie:

RP/0/RSP0/CPU0:XR-RTR#sh run int te0/0/2/3
interface TenGigE0/0/2/3
 ipv4 address 172.16.0.9 255.255.255.252

i wszystko jasne. maska /30 powoduje, że ’nowy’ adres 172.16.0.11 może i jest rozgłaszany przez OSPF, ale nie możemy wysyłać do niego ruchu skoro jest adresem rozgłoszeniowym na jednym z aktywnych interfejsów.

podsumowanie

używajcie IPAMa. nawet jeśli to Excel, ale niech to będzie uporządkowany Excel :)