Routes et sauts suivants

Argo conserve l’état de transfert séparé du noyau Linux. Lorsque ip et ces commandes ne concordent pas, ce sont ces commandes qui acheminent le trafic.

rt

La table de routage vRouter, par 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

L'identifiant VRF n'est pas celui que BGP rapporte

show-ip-bgp-summary affiche vrf-id 3. Il s’agit de la numérotation FRR et il s’agit d’un espace de nommage différent de l’identifiant de table vRouter. Le passer ici échoue d’une manière qui se présente comme un nœud défaillant :

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

La même réponse est renvoyée pour --dump 0. Sur cette topologie, VRF 2 est la table inet4 remplie, avec VRF 1 contenant deux routes. Si vous ne connaissez pas l’identifiant, sondez vers le haut à partir de 1 plutôt que de vous fier à la sortie BGP.

nh

La table des sauts suivants. Chaque route pointe vers un identifiant de saut suivant, et ceci les résout.

{"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]

Chaque entrée comporte un Type et le VRF auquel elle appartient. Huit types apparaissent sur ces nœuds, dans ces proportions — identiques sur les trois CE lorsqu’ils sont comptés :

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

Une route se résolvant vers un saut suivant Drop est un trou noir, et cette combinaison vaut la peine d’être vérifiée chaque fois qu’un préfixe est présent dans rt alors que le trafic disparaît quand même.

La capture ci-dessus est tronquée et ne contient donc pas tous les types

Il s’agit des 60 premières lignes sur 3 849. Tunnel, le type de loin le plus courant, n’apparaît pas du tout dans ces 60 lignes — ne lisez donc pas la capture comme l’inventaire complet des types, et ne concluez pas qu’un type est absent d’un nœud parce qu’il est absent d’une capture tronquée. Les comptages ci-dessus proviennent de la réponse non tronquée.

vif

La table des interfaces virtuelles : ce à quoi le plan de données se lie, ainsi que les compteurs par interface.

{"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]

La légende des indicateurs en haut mérite d’être lue une fois — Vp marque l’interface physique vhost, Dpdk une interface gérée par DPDK. Utilisez ceci pour confirmer que le plan de données a réclamé l’interface attendue, et pour consulter les compteurs RX et TX que Linux n’affiche pas car le trafic n’atteint jamais le noyau.

mpls

execcli mpls --help

La table MPLS Argo. Accessible uniquement depuis la machine — mpls n’est pas sur l’API de débogage, donc contrairement à rt, nh et vif ci-dessus, il nécessite SSH ou la console série, via execcli.

Aucune sortie capturée ici. Sur ce déploiement, le CE transfère IPv4 avec BGP et ECMP et n’utilise pas d’étiquettes MPLS, donc une capture montrerait une table vide sans rien enseigner. Son existence et la forme de son argument --help sont vérifiées depuis le menu de complétion propre à l’appliance ; sa sortie remplie n’est pas reproduite.