vrf-table-label

    Heute werden wir über den Befehl vrf-table-label sprechen. Lassen Sie uns zunächst die Methoden zur Erzeugung von vrf-Tags in Erinnerung rufen. Tags können auf drei Arten generiert werden: per-vrf, per-prefix und per-next-hop.

    Pro-Präfix - ein Label - ein Client-Präfix, dh wenn wir 100 Client-VRFS haben und jeder Client 100 Präfixe hat, erhalten wir 100x100 = 10.000 Labels, was nach heutigen Maßstäben sehr verschwenderisch ist. Diese Methode zum Verteilen von vrf-Tags wird standardmäßig auf Cisco-Routern verwendet.

    per-next-hop - Ein Label für alle Client-Präfixe, die den gleichen next-hop haben. Wenn der Client-Router über eine Verbindung mit dem PE-Router verbunden ist, haben alle Präfixe denselben Next-Hop, dh dieselbe Bezeichnung. Dieser Mechanismus zum Verteilen von vrf-Bezeichnungen ist in JunOS standardmäßig aktiviert.

    per-vrf - ein Etikett für den gesamten vrf. Aus Sicht der Etikettenverteilung ist dieser Modus sehr sparsam: Wenn wir 100 Client-VRFS haben und jeder Client 100 Präfixe hat, erhalten wir 100x1 = 100 Etiketten. Bei dieser Verteilung von vrf-Labels muss der Router zusätzlich zur mpls-Suche eine IP-Suche durchführen.

    Wie oben beschrieben, verwendet JunOS standardmäßig die Labelverteilung pro nächster Hop. Wenn Sie dieses Verhalten ändern möchten, müssen Sie den Befehl vrf-table-label eingeben (für Fans verwirrter Konfigurationen kann der Mechanismus zur Verteilung von Beschriftungen mithilfe der Richtlinie festgelegt werden) oder den Tunnel-PIC verwenden. Nun wollen wir sehen, wie alles mit diesem Team und ohne es funktioniert. Wir werden dieses Schema mit Option C verwenden.

    Ohne den Befehl vrf-table label (und das Erstellen der vt-Schnittstelle).
    Die vrf-Konfiguration auf PE1 lautet wie folgt:
    bormoglotx@PE1> show configuration routing-instances CE1
    instance-type vrf;
    interface ge-0/0/3.10;
    interface ge-0/0/3.20;
    route-distinguisher 1:1;
    vrf-target {
        import target:2:100;
        export target:2:100;
    }
    protocols {
        ospf {
            export ospf-export;
            area 0.0.0.0 {
                interface ge-0/0/3.10;
                interface ge-0/0/3.20;
            }
        }
    }
    

    bormoglotx@PE1> show configuration interfaces ge-0/0/3
    description "to SW1";
    vlan-tagging;
    unit 10 {
        description "to CE1 site 1";
        vlan-id 10;
        family inet {
            address 10.0.0.1/24;
        }
    }
    unit 20 {
        description "to CE1 site 2";
        vlan-id 20;
        family inet {
            address 20.0.0.1/24;
        }
    }
    

    Dementsprechend beginnt der Router, vpnv4-Präfixe zu generieren und diese an die Router-Reflektoren zu senden. In unserem Fall hat der Router die Adresse 10.0.10.10:
    bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10
    CE1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
      Prefix                  Nexthop              MED     Lclpref    AS path
    * 10.0.0.0/24             Self                         100        I
    * 10.1.1.1/32             Self                 2       100        I
    * 20.0.0.0/24             Self                         100        I
    * 20.1.1.1/32             Self                 2       100        I
    

    PE1 sendet vier Routen an den Reflektor: zwei verbundene Netzwerke und zwei / 32 (CE-Router-Router), die es über ospf empfängt. Mal sehen, welche Bezeichnungen für diese Präfixe generiert wurden:
    bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10 detail
    CE1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
    * 10.0.0.0/24 (1 entry, 1 announced)
     BGP group RR type Internal
         Route Distinguisher: 1:1
         VPN Label: 299888
         Nexthop: Self
         Flags: Nexthop Change
         Localpref: 100
         AS path: [1] I
         Communities: target:2:100
    * 10.1.1.1/32 (1 entry, 1 announced)
     BGP group RR type Internal
         Route Distinguisher: 1:1
         VPN Label: 299888
         Nexthop: Self
         Flags: Nexthop Change
         MED: 2
         Localpref: 100
         AS path: [1] I
         Communities: target:2:100 rte-type:0.0.0.0:1:0
    * 20.0.0.0/24 (1 entry, 1 announced)
     BGP group RR type Internal
         Route Distinguisher: 1:1
         VPN Label: 299904
         Nexthop: Self
         Flags: Nexthop Change
         Localpref: 100
         AS path: [1] I
         Communities: target:2:100
    * 20.1.1.1/32 (1 entry, 1 announced)
     BGP group RR type Internal
         Route Distinguisher: 1:1
         VPN Label: 299904
         Nexthop: Self
         Flags: Nexthop Change
         MED: 2
         Localpref: 100
         AS path: [1] I
         Communities: target:2:100 rte-type:0.0.0.0:1:0
    

    Aus Gründen der Klarheit wählen wir aus den Schlussfolgerungen nur die Werte der Etiketten aus:
    bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10 detail | match label
         VPN Label: 299888
         VPN Label: 299888
         VPN Label: 299904
         VPN Label: 299904
    

    Es ist zu sehen, dass für Präfixe aus dem Bereich 10.0.0.0/8 das Label 299888 und für Präfixe aus dem Bereich 20.0.0.0/8 das Label 299904 generiert wird. Es gibt jedoch eine nicht sehr angenehme Nuance - in diesem Fall erzeugt JunOS keine IP-Suche. Was droht das? Sie können keine Filter verwenden, da der IP-Header nicht analysiert wird.

    Lassen Sie es uns in der Praxis überprüfen.
    Gemäß der folgenden Schlussfolgerung sendet PE1, nachdem es ein Paket mit dem Label 299904 erhalten hat, es einfach an die ge-0/0 / 3.20-Schnittstelle:
    bormoglotx@PE1> show route table mpls.0 label 299904
    mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    299904             *[VPN/170] 00:46:19
                        > to 20.0.0.2 via ge-0/0/3.20, Pop
    

    und für Pakete mit der Bezeichnung 299888 - in der Schnittstelle ge-0/0 / 3.10:
    bormoglotx@PE1> show route table mpls.0 label 299888
    mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    299888             *[VPN/170] 00:46:25
                        > to 10.0.0.2 via ge-0/0/3.10, Pop
    

    Wie Sie sehen, entfernt der Router das Etikett und sendet das Paket abhängig vom eingehenden Etikett an die Schnittstelle, ohne eine IP-Suche durchzuführen, wie wir jetzt sehen werden.

    Auf vpnv4-Routen auf PE2 prüfen:
    PE2#sh ip bgp vpnv4 rd 1:1 labels
       Network          Next Hop      In label/Out label
    Route Distinguisher: 1:1
       10.0.0.0/24      10.0.10.1       nolabel/299888
       10.1.1.1/32      10.0.10.1       nolabel/299888
       20.0.0.0/24      10.0.10.1       nolabel/299904
       20.1.1.1/32      10.0.10.1       nolabel/299904
    

    Schauen wir uns nun die Routing-Tabelle auf CE2 an:
    CE2#sh ip rou | b Ga
    Gateway of last resort is not set
          10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
    O E2     10.0.0.0/24 [110/10] via 10.0.1.1, 00:22:32, GigabitEthernet1/0.10
    C        10.0.1.0/24 is directly connected, GigabitEthernet1/0.10
    L        10.0.1.2/32 is directly connected, GigabitEthernet1/0.10
    O E2     10.1.1.1/32 [110/10] via 10.0.1.1, 00:22:32, GigabitEthernet1/0.10
    C        10.1.1.2/32 is directly connected, Loopback0
          20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
    O E2     20.0.0.0/24 [110/10] via 10.0.1.1, 00:22:32, GigabitEthernet1/0.10
    O E2     20.1.1.1/32 [110/10] via 10.0.1.1, 00:22:32, GigabitEthernet1/0.10
    

    Alles ist gut - es gibt Strecken. Jetzt können wir den Trace auf 20.0.0.2 - Adresse CE1-2 ausführen:
    CE2#traceroute 20.0.0.2
    Type escape sequence to abort.
    Tracing the route to 20.0.0.2
      1 10.0.1.1 36 msec 32 msec 8 msec
      2 10.1.3.2 [MPLS: Labels 20/18/299904 Exp 0] 56 msec 64 msec 60 msec
      3 10.1.2.1 [MPLS: Labels 18/299904 Exp 0] 72 msec 108 msec 40 msec
      4 10.2.0.1 [MPLS: Labels 299952/299904 Exp 0] 60 msec 88 msec 60 msec
      5 10.0.3.2 [MPLS: Labels 299808/299904 Exp 0] 76 msec 68 msec 64 msec
      6 10.0.2.1 [MPLS: Label 299904 Exp 0] 60 msec 52 msec 64 msec
      7 20.0.0.2 60 msec 60 msec 56 msec
    

    Alles ist vorhersehbar - Standardablaufverfolgung durch Option C.

    Beginnen wir nun mit der Ablaufverfolgung bis 20.0.0.1 - dies ist die Adresse der PE1-Schnittstelle zur Clientseite (die Schnittstellenkonfiguration wird ganz am Anfang des Artikels angezeigt):
    CE2#traceroute 20.0.0.1
    Type escape sequence to abort.
    Tracing the route to 20.0.0.1
      1 10.0.1.1 40 msec 4 msec 16 msec
      2 10.1.3.2 [MPLS: Labels 20/18/299904 Exp 0] 80 msec 64 msec 60 msec
      3 10.1.2.1 [MPLS: Labels 18/299904 Exp 0] 56 msec 60 msec 72 msec
      4 10.2.0.1 [MPLS: Labels 299952/299904 Exp 0] 48 msec 76 msec 112 msec
      5 10.0.3.2 [MPLS: Labels 299808/299904 Exp 0] 68 msec 96 msec 64 msec
      6 10.0.2.1 [MPLS: Label 299904 Exp 0] 80 msec 68 msec 4 msec
      7 20.0.0.2 92 msec 72 msec 64 msec
      8 20.0.0.1 96 msec 48 msec 88 msec
    

    Wenn wir die Ausgabe mit der vorherigen vergleichen, sehen wir, dass bis zu 20.0.0.1 ein Sprung mehr ist. Wie also, denn 20.0.0.1 ist das Gateway zum Netzwerk 20.0.0.0/24? Wenn Sie genau hinschauen, sehen wir, dass ein Paket vom PE-Router (10.0.2.1 - Core Facing Interface) an den CE-Router (Adresse 20.0.0.2) gesendet und an den PE-Router (20.0.0.1) zurückgesendet wurde. Wie gesagt, JunOS hat keine IP-Suche durchgeführt und das Paket einfach an die Client-Schnittstelle weitergeleitet, aber der Client-Router hat die Zieladresse des IP-Pakets überprüft und an PE1 zurückgesendet (siehe folgende Abbildung):

    In unserem Fall hat der Router das Paket mit dem Etikett empfangen Vom Netzwerkkern aus schaute man sich in der Tabelle mpls.0 an, was mit dem Paket zu tun ist, deaktivierte es und schickte es an die Schnittstelle zum Client.

    Wenn wir einen Filter an unserem PE-Router an der Client-Schnittstelle aufhängen oder qos konfigurieren, wird der Datenverkehr in Anbetracht der obigen Ausführungen nicht entsprechend den installierten Filtern verarbeitet.

    Wir hängen einen Filter auf der Clientseite auf:
    bormoglotx@PE1# show firewall family inet filter To-CE1-2
    term 1 {
        from {
            destination-address {
                20.0.0.0/24;
            }
        }
        then {
            reject;
        }
    }
    term 2 {
        then accept;
    }
    [edit]
    bormoglotx@PE1# show interfaces ge-0/0/3.20
    description "to CE1 site 2";
    vlan-id 20;
    family inet {
        filter {
            output To-CE1-2;
        }
        address 20.0.0.1/24;
    }
    

    Führen Sie nun mit CE2 den Befehl ping an das Netzwerk 20.0.0.0/24 aus:
    CE2#ping 20.0.0.2
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 20.0.0.2, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 64/69/72 ms
    

    Es gibt einen Filter, aber er funktioniert nicht. Ändern Sie diese Situation, indem Sie die Option vrf-table label aktivieren:
    [edit]
    bormoglotx@PE1# set routing-instances CE1 vrf-table-label
    

    Versuchen wir noch einmal, mit CE2 einen Ping an das Netzwerk 20.0.0.0/24 zu senden:
    CE2#ping 20.0.0.2
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 20.0.0.2, timeout is 2 seconds:
    UUUUU
    Success rate is 0 percent (0/5)
    

    Jetzt ist der Host nicht erreichbar - der Filter erfüllt. Entfernen Sie den Filter und wiederholen Sie den Ping-Vorgang, um Folgendes zu überprüfen:
    [edit]
    bormoglotx@PE1# deactivate interfaces ge-0/0/3.20 family inet filter
    [edit]
    bormoglotx@PE1# show | compare
    [edit interfaces ge-0/0/3 unit 20 family inet]
    !        inactive: filter { ... }
    

    CE2#ping 20.0.0.2
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 20.0.0.2, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 60/88/148 ms
    

    Alles in Ordnung ist. Jetzt haben wir deutlich gesehen, welche Fallstricke uns mit dem Standardmechanismus für die Verteilung von vrf-Labels in JunOS erwarten. Da wir bereits den Befehl vrf-table-label gegeben und den Filter oben deaktiviert haben, werden wir den Betrieb des Routers mit aktivierter Option vrf-table-label erörtern .

    Sehen wir uns die Routen an, die PE1 dem
    Routenreflektor mitteilt : bormoglotx @ PE1> show route advertising-protocol bgp 10.0.10.10
    CE1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
      Prefix                  Nexthop              MED     Lclpref    AS path
    * 10.0.0.0/24             Self                         100        I
    * 10.1.1.1/32             Self                 2       100        I
    * 20.0.0.0/24             Self                         100        I
    * 20.1.1.1/32             Self                 2       100        I
    

    bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10 detail
    CE1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
    * 10.0.0.0/24 (1 entry, 1 announced)
     BGP group RR type Internal
         Route Distinguisher: 1:1
         VPN Label: 16
         Nexthop: Self
         Flags: Nexthop Change
         Localpref: 100
         AS path: [1] I
         Communities: target:2:100
    * 10.1.1.1/32 (1 entry, 1 announced)
     BGP group RR type Internal
         Route Distinguisher: 1:1
         VPN Label: 16
         Nexthop: Self
         Flags: Nexthop Change
         MED: 2
         Localpref: 100
         AS path: [1] I
         Communities: target:2:100 rte-type:0.0.0.0:1:0
    * 20.0.0.0/24 (1 entry, 1 announced)
     BGP group RR type Internal
         Route Distinguisher: 1:1
         VPN Label: 16
         Nexthop: Self
         Flags: Nexthop Change
         Localpref: 100
         AS path: [1] I
         Communities: target:2:100
    * 20.1.1.1/32 (1 entry, 1 announced)
     BGP group RR type Internal
         Route Distinguisher: 1:1
         VPN Label: 16
         Nexthop: Self
         Flags: Nexthop Change
         MED: 2
         Localpref: 100
         AS path: [1] I
         Communities: target:2:100 rte-type:0.0.0.0:1:0
    

    Wie Sie sehen können, haben wir jetzt nur eine Bezeichnung für alle Routen von vrf CE1:
    bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10 detail | match label
         VPN Label: 16
         VPN Label: 16
         VPN Label: 16
         VPN Label: 16
    

    Führen Sie den Trace erneut von CE2 auf 20.0.0.1 aus:
    CE2#traceroute 20.0.0.1
    Type escape sequence to abort.
    Tracing the route to 20.0.0.1
      1 10.0.1.1 32 msec 16 msec 20 msec
      2 10.1.3.2 [MPLS: Labels 20/18/16 Exp 0] 76 msec 48 msec 68 msec
      3 10.1.2.1 [MPLS: Labels 18/16 Exp 0] 68 msec 48 msec 56 msec
      4 10.2.0.1 [MPLS: Labels 299952/16 Exp 0] 52 msec 48 msec 52 msec
      5 10.0.3.2 [MPLS: Labels 299808/16 Exp 0] 52 msec 52 msec 52 msec
      6 20.0.0.1 76 msec 52 msec 72 msec
    

    Jetzt durchlaufen ICMP-Pakete CE1-2 nicht mehr.
    Die Route selbst auf PE1 sieht jetzt etwas anders aus:
    bormoglotx@PE1> show route table mpls.0 label 16
    mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    16                 *[VPN/0] 00:04:23
                          to table CE1.inet.0, Pop
    

    In der gewöhnlichen Sprache müssen Sie beim Empfang eines Pakets mit der Bezeichnung 16 das Häkchen entfernen und die IP-Suche in Tabelle CE1.inet.0 durchführen. Warum ist diese Funktion in Juniper beim Generieren von per-nex-hop-Tags nicht implementiert? Es geht um die Hardware-Architektur von Juniper - PFE kann nicht gleichzeitig MPLs und IP-Adressen suchen. Um eine doppelte Suche zu implementieren, benötigen wir den sogenannten Tunnel Services PIC, dann den Tunnel PIC (vt-fpc / pic / port.unit-number-Schnittstelle). So sieht der PIC im M120-Chassis aus:

    Hinweis: Informationen zum Erstellen und Hinzufügen einer VT-Schnittstelle zu VRF finden Sie hier

    Nun wird der Paketverarbeitungsalgorithmus geändert: Der Router hat das Paket mit dem Etikett vom Netzwerkkern empfangen, in der Tabelle mpls.0 nachgesehen, was mit dem Paket zu tun ist, und es deaktiviert und an die vt-Schnittstelle gesendet. Dann geht das Paket von der vt-Schnittstelle erneut an PFE, jedoch ohne Etikett und PFE kann eine IP-Suche durchführen (und diese dann an den Client senden).

    Das Erfordernis eines Tunnel-PIC führt jedoch zu gewissen Einschränkungen bei der Verwendung dieser Funktion. Wenn Sie über keinen solchen PIC verfügen, können Sie den Befehl vrf-table-label eingeben, und JunOS erstellt automatisch eine virtuelle lsi-Schnittstelle (Label Switching Interface) (von Plattformen der ACX-, M-, MX- und T-Serie unterstützt), die genau dieselbe Funktion ausführt wie VT-Schnittstelle:
    bormoglotx@PE1> show interfaces terse | match lsi
    lsi                     up    up
    lsi.0                   up    up   inet
    

    Diese Schnittstelle steht für die Konfiguration nicht zur Verfügung. Für jede vrf wird eine separate lsi-Schnittstelle erstellt, die dem für diese vrf generierten Label zugeordnet ist. Erstellen Sie z. B. einen anderen VRF und sehen Sie, wie viele LSI-Schnittstellen jetzt vorhanden sind:
    bormoglotx@PE1> show configuration routing-instances ?
    Possible completions:
      <[Enter]>            Execute this command
            Routing instance name
      CE1                  Routing instance name
      CE2                  Routing instance name
    + apply-groups         Groups from which to inherit configuration data
    + apply-groups-except  Don't inherit configuration data from these groups
      |                    Pipe through a command
    

    bormoglotx@PE1> show interfaces terse | match lsi
    lsi                     up    up
    lsi.0                   up    up   inet
    lsi.1                   up    up   inet
    


    Mit dem Befehl: show interfaces lsi routing-instance instance-name können Sie sehen, welche lsi-Einheit einer Routing-Instanz entspricht. Beispiel:
    bormoglotx@PE1> show interfaces lsi routing-instance CE1 | match logical
      Logical interface lsi.0 (Index 71) (SNMP ifIndex 524)
    bormoglotx@PE1> show interfaces lsi routing-instance CE2 | match logical
      Logical interface lsi.1 (Index 81) (SNMP ifIndex 525)
    

    Die lsi-Schnittstelle wurde auch für die Routing-Instanz vpls (Befehl no-tunnel-services) erstellt. Der Datenverkehr wird in diesem Fall wie oben beschrieben verarbeitet, mit der Ausnahme, dass vpls ausschließlich mit Mac-Adressen arbeitet und nichts über Client-IP-Adressen weiß, dies jedoch vollständig ist eine andere Geschichte.

    Vielen Dank für Ihre Aufmerksamkeit!

    Jetzt auch beliebt: