Routen und Next-Hops

Argo hält den Weiterleitungszustand von dem Linux-Kernel getrennt. Wenn ip und diese Befehle nicht übereinstimmen, sind diese Befehle ausschlaggebend für den Datenverkehr.

rt

Die vRouter-Routentabelle, pro VRF.

{"command":["rt","--dump","2"]}

Flags: L=Label Valid, P=Proxy ARP, T=Trap ARP, F=Flood ARP, H=Proxy ARP for host interface, V=Preferred VRF
Labels/Misc: S=SiteId N=NetworkId
vRouter inet4 routing table 0/2/unicast
Destination           PPL        Flags        Label         Nexthop  Labels/Misc
                                 Number of routes: 4

0.0.0.0/0               0                       -              0
169.254.254.102/32     32            L        263             13
172.16.12.126/32       32            L          0             46     (S,N):2298:0
172.16.84.126/32       32            L          0             46     (S,N):2298:0

Die VRF-ID ist nicht dieselbe, die BGP meldet

show-ip-bgp-summary gibt vrf-id 3 aus. Das ist die Nummerierung von FRR und gehört einem anderen Namensraum als die vRouter-Tabellen-ID an. Die Übergabe dieser ID schlägt auf eine Weise fehl, die wie ein defekter Knoten aussieht:

vRouter(Response):  [No such file or directory (2)]

Dieselbe Antwort kommt bei --dump 0 zurück. In dieser Topologie ist VRF 2 die befüllte inet4-Tabelle, wobei VRF 1 zwei Routen enthält. Wenn die ID nicht bekannt ist, sollte man von 1 aufwärts suchen, anstatt der BGP-Ausgabe zu vertrauen.

nh

Die Next-Hop-Tabelle. Jede Route verweist auf eine Next-Hop-ID, und diese löst sie auf.

{"command":["nh","--list"]}

Id:0          Type:Drop           Fmly: AF_INET  Rid:0  Vrf:0
              Flags:Valid, Tunnel: None

Id:1          Type:Drop           Fmly: AF_INET  Rid:0  Vrf:0
              Flags:Valid, Tunnel: None

Id:2          Type:Receive        Fmly: AF_INET  Rid:0  Vrf:1
              Flags:Valid, Policy, Tunnel: Udp,
              Oif:0

Id:3          Type:Receive        Fmly: AF_INET  Rid:0  Vrf:2
              Flags:Valid, Policy, Tunnel: Udp,
              Oif:0

Id:4          Type:Receive        Fmly: AF_INET  Rid:0  Vrf:3
              Flags:Valid, Policy, Tunnel: Udp,
              Oif:0

Id:5          Type:Receive        Fmly: AF_INET  Rid:0  Vrf:4
              Flags:Valid, Policy, Tunnel: Udp,
              Oif:0

Id:6          Type:Vrf_Translate  Fmly: AF_INET  Rid:0  Vrf:1
              Flags:Valid, Policy, Tunnel: None

Id:7          Type:Vrf_Translate  Fmly: AF_INET  Rid:0  Vrf:2
              Flags:Valid, Policy, Tunnel: None

Id:8          Type:Vrf_Translate  Fmly: AF_INET  Rid:0  Vrf:3
              Flags:Valid, Policy, Tunnel: None

Id:9          Type:Vrf_Translate  Fmly: AF_INET  Rid:0  Vrf:4
              Flags:Valid, Policy, Tunnel: None

Id:10         Type:Vrf_Translate  Fmly: AF_INET  Rid:0  Vrf:5
              Flags:Valid, Policy, Tunnel: None

Id:11         Type:Vrf_Translate  Fmly: AF_INET  Rid:0  Vrf:6
              Flags:Valid, Policy, Tunnel: None

Id:12         Type:Encap          Fmly: AF_INET  Rid:0  Vrf:1
              Flags:Valid, Policy, Tunnel: None
              Oif:2  Len:14
              Encap Data: 02 01 02 03 04 05 00 00 5e 00 01 00 08 00

Id:13         Type:Encap          Fmly: AF_INET  Rid:0  Vrf:2
              Flags:Valid, Policy, Tunnel: None
              Oif:4  Len:14
              Encap Data: 02 01 02 03 04 06 00 00 5e 00 01 00 08 00

Id:14         Type:Encap          Fmly: AF_INET  Rid:0  Vrf:3
              Flags:Valid, Policy, Tunnel: None
              Oif:6  Len:14
              Encap Data: 00 00 5e 00 02 00 00 00 5e 00 01 00 08 00

Id:15         Type:Encap          Fmly: AF_INET  Rid:0  Vrf:6
              Flags:Valid, Policy, Tunnel: None
              Oif:10  Len:14
              Encap Data: 02 01 02 03 04 09 00 00 5e 00 01 00 08 00


... [capture trimmed: first 60 of 3820 lines]

Jeder Eintrag enthält einen Type und das zugehörige VRF. Auf diesen Knoten kommen acht Typen vor, in folgenden Anteilen — identisch über alle drei CEs hinweg:

Tunnel 558   Encap 27   NAT 22   Vrf 16   Receive 14   Composite 4   Drop 2   Resolve 2

Eine Route, die zu einem Drop-Next-Hop aufgelöst wird, ist ein Blackhole. Diese Kombination sollte immer dann überprüft werden, wenn ein Präfix in rt vorhanden ist, der Datenverkehr aber trotzdem verschwindet.

Die obige Aufzeichnung ist gekürzt und enthält daher nicht jeden Typ

Es handelt sich um die ersten 60 Zeilen von 3.849. Tunnel, der mit Abstand häufigste Typ, kommt in diesen 60 Zeilen gar nicht vor — daher sollte die Aufzeichnung nicht als vollständiges Typinventar gelesen werden, und es sollte nicht der Schluss gezogen werden, dass ein Typ auf einem Knoten fehlt, weil er in einer gekürzten Aufzeichnung fehlt. Die obigen Zählungen stammen aus der vollständigen Antwort.

vif

Die virtuelle Schnittstellentabelle: womit die Datenebene verknüpft ist, und Zähler pro Schnittstelle.

{"command":["vif","--list"]}

Vrouter Interface Table

Flags: P=Policy, X=Cross Connect, S=Service Chain, Mr=Receive Mirror
       Mt=Transmit Mirror, Tc=Transmit Checksum Offload, L3=Layer 3, L2=Layer 2
       D=DHCP, Vp=Vhost Physical, Pr=Promiscuous, Vnt=Native Vlan Tagged
       Mnp=No MAC Proxy, Dpdk=DPDK PMD Interface, Rfl=Receive Filtering Offload, Mon=Interface is Monitored
       Nf=Dont Fragment, Vof=VLAN insert/strip offload, Mq=MultiQ, L=MAC Learning Enabled
       Proxy=MAC Requests Proxied Always, Fr=Force Recv, Mn=Mirror without Vlan Tag, TTL=TTL not modified
       Mn=Mirror without Vlan Tag, Tun=Tunnel, NoArp=No ARP interface, RawIp=RAW IP interface(No L2 header)
       Npers=Non-Persistent, NoRPF=No RPF Checks, SynC=Syn Cookies, Gro=GRO Enabled
       NoIpfix=IPFIX disabled

evif0/1     Virtual: eth0 (Speed 10000, Duplex 1) Parent:vif0/-1
            Type:Physical HWaddr:60:45:bd:eb:3f:f2  Driver: net_failsafe
            CrossConnectIdx: 2 PartnerIdx: 14
            Vrf:0 Mcast Vrf:0 VN:0x0 Flags:L3L2Vp Ref:7
            MTU: 1500 EncMSS: 0 NH: 0
            RX device packets:386252  bytes:355098338 errors:0
            RX port   packets:386252 errors:0
            RX queue  packets:385977 errors:0
            RX queue errors to lcore 0 0 0 0 0 0 0 0 0 0 0 0 0 0
            RX packets:386252  bytes:355098338 errors:0
            TX packets:274826  bytes:132476854 errors:0
            Drops:0
            TX queue  packets:27 errors:0
            TX port   packets:274826 errors:0
            TX device packets:274826  bytes:132476854 errors:0

evif0/2     Virtual: vhost0 Parent:vif0/-1
            Type:Host HWaddr:60:45:bd:eb:3f:f2  Driver: vr_dpdk_tap
            CrossConnectIdx: 1 PartnerIdx: 15
            Vrf:0 Mcast Vrf:0 VN:0x0 Flags:L3L2 Ref:6
            MTU: 1500 EncMSS: 0 NH: 0
            RX device packets:263582  bytes:122772389 errors:0
            RX queue  packets:263582 errors:0
            RX queue errors to lcore 0 0 0 0 0 0 0 0 0 0 0 0 0 0
            RX packets:263582  bytes:120136569 errors:0
            TX packets:374276  bytes:343331787 errors:0
            Drops:0
            TX queue  packets:370829 errors:3447
            TX device packets:370820  bytes:341968151 errors:9

vif0/2      Ethernet: vethfrr0 Parent:vif0/-1
            Type:Virtual HWaddr:0:0:5e:0:1:0  Driver: net_af_packet
            Vrf:1 Mcast Vrf:1 VN:0x0 Flags:PL3Proxy Ref:10
            MTU: 1500 EncMSS: 130 NH: 12
            RX port   packets:4919 errors:0
            RX queue  packets:4917 errors:0
            RX queue errors to lcore 0 0 0 0 0 0 0 0 0 0 0 0 0 0
            RX packets:907  bytes:153742 errors:0
            TX packets:6  bytes:444 errors:0
            Drops:905
            TX queue  packets:346 errors:0
            TX port   packets:3987 errors:0
            Ingress ACL: 65 67
            Egress ACL: 65 67
            Service ACL: 65 67

vif0/4      Ethernet: vethbfd0 Parent:vif0/-1
            Type:Virtual HWaddr:0:0:5e:0:1:0  Driver: net_af_packet

... [capture trimmed: first 60 of 378 lines]

Die Flags-Legende am Anfang ist es wert, einmal gelesen zu werden — Vp markiert die physische vhost-Schnittstelle, Dpdk eine DPDK-verwaltete. Damit lässt sich bestätigen, dass die Datenebene die erwartete Schnittstelle übernommen hat, und RX- sowie TX-Zähler anzeigen, die Linux nicht anzeigt, weil der Datenverkehr den Kernel nie erreicht.

mpls

execcli mpls --help

Die Argo-MPLS-Tabelle. Nur vom Gerät selbst erreichbar — mpls ist nicht in der Debug-API, daher benötigt es im Gegensatz zu rt, nh und vif oben SSH oder die serielle Konsole, über execcli.

Hier gibt es keine aufgezeichnete Ausgabe. In dieser Bereitstellung leitet der CE IPv4 mit BGP und ECMP weiter und verwendet keine MPLS-Labels, sodass eine Aufzeichnung eine leere Tabelle zeigen und nichts lehren würde. Ihre Existenz und die Form ihres --help-Arguments sind über das Vervollständigungsmenü des Geräts selbst verifiziert; die befüllte Ausgabe wird hier nicht wiedergegeben.