JUNIPER: Warum bricht die OSPF-Adjazenz, wenn ich FBF auf einer OSPF-Schnittstelle aktiviere?


9

Ich habe ein Testlabor eingerichtet, in dem ich Filter Based Forwarding (FBF), auch bekannt als Policy Based Routing, teste. Die Frage folgt unten, aber zuerst die Details:

Unten ist das Topologiediagramm:

Geben Sie hier die Bildbeschreibung ein

ZIEL: Jeder Datenverkehr, der für die Bereitstellung von Standort 1 bestimmt ist, sollte über Link 2 in das WAN und NICHT über Link 1 geleitet werden. Da Link 1 mit Replikationsverkehr zwischen den beiden Rechenzentren gesättigt ist.

  • SW-1 und SW-2 sind Juniper EX4200-Schalter
  • RTR-1 und RTR-2 sind Juniper J4350
  • PE-1 und PE-2 sind Cisco 1841-Router, auf denen ISIS und MPLS VPN ausgeführt werden, um das WAN-Backbone des Anbieters zu simulieren

SW-1, SW-2, RTR-1 und RTR-2 sind alle OSPF-Nachbarn in Bereich 0. Sowohl RTR-1 als auch RTR-2 sind ASBRs und injizieren BGP-Lernrouten in OSPF. Jeder Router kündigt Routen in das WAN für seinen jeweiligen Standort an (sowie vorab ausstehende Routen für den anderen Standort aus Redundanzgründen).

Das Weiterleiten des Datenverkehrs von Standort 1 zu Staging an Standort 2 kann einfach durch Umverteilen der statischen Route zu Staging auf SW-2 in OSPF mit einer höheren Metrik erreicht werden. Da diese Route von RTR-2 in das WAN angekündigt wird, lernt RTR-1 diese Route und verteilt sie mit einer Metrik von 0 in OSPF. Die auf SW-1 von SW-2 gelernte OSPF-Route hätte daher eine höhere Metrik Routing wäre dem WAN vorzuziehen.

Der Rückverkehr von Standort 2 muss ebenfalls auf diese Weise fließen, damit asymmetrisches Routing vermieden wird. FBF wird auf die eingehende Schnittstelle (Link 4) angewendet, die in SW-2 eintritt. Dieser Filter nimmt den gesamten von Staging (10.100.190 / 24) bezogenen Datenverkehr auf und erstellt den RTR-2 für den nächsten Hop. Dieser Teil der FBF funktioniert, wie ich im Labor getestet habe.

Da die bevorzugte Route von RTR-2 zurück zu Standort 1 über Link 1 erfolgt, müssen wir FBF erneut an der eingehenden LAN-Schnittstelle von RTR-2 (gegenüber SW-2) anwenden.

Hier ist das Problem ... Wenn FBF auf diesen Router angewendet wird, wird die OSPF-Nachbarschaft mit SW-2 unterbrochen.

FRAGE: Warum bricht die OSPF-Nachbarschaft zwischen RTR-2 und SW-2?

Die Konfiguration für RTR-2 und SW-2 ist beigefügt:

RTR-2-Konfigurationen

root@RTR-2> show configuration interfaces | display set    
set interfaces ge-0/0/0 unit 0 family inet filter input FBF-TEST
deactivate interfaces ge-0/0/0 unit 0 family inet filter
set interfaces ge-0/0/0 unit 0 family inet address 10.100.254.2/24
set interfaces ge-0/0/3 description "Uplink to WAN"
set interfaces ge-0/0/3 unit 0 family inet address 200.200.200.2/30
set interfaces lo0 unit 0 family inet address 10.100.199.4/32

root@RTR-2> show configuration routing-options | display set 
set routing-options interface-routes rib-group inet STAGING-RIB
set routing-options rib-groups STAGING-RIB import-rib inet.0
set routing-options rib-groups STAGING-RIB import-rib PATH-1.inet.0
set routing-options rib-groups STAGING-RIB import-rib PATH-2.inet.0
set routing-options router-id 200.200.200.2
set routing-options autonomous-system 1

root@RTR-2> show configuration routing-instances | display set  
set routing-instances PATH-1 instance-type forwarding
set routing-instances PATH-1 routing-options static route 10.100.30.0/24 next-hop 200.200.200.1
set routing-instances PATH-1 routing-options static route 10.100.30.0/24 qualified-next-hop 10.100.254.1 preference 100
set routing-instances PATH-2 instance-type forwarding
set routing-instances PATH-2 routing-options static route 10.100.30.0/24 next-hop 10.100.254.1
set routing-instances PATH-2 routing-options static route 10.100.30.0/24 qualified-next-hop 200.200.200.1 preference 100

root@RTR-2> show configuration firewall | display set             
set firewall family inet filter FBF-TEST term TERM-1 from source-address 10.100.190.0/24
set firewall family inet filter FBF-TEST term TERM-1 from source-address 10.100.191.0/24
set firewall family inet filter FBF-TEST term TERM-1 then routing-instance PATH-1
set firewall family inet filter FBF-TEST term DEFAULT then routing-instance PATH-2

root@RTR-2> show configuration protocols | display set 
set protocols bgp path-selection cisco-non-deterministic
set protocols bgp log-updown
set protocols bgp group TEST type external
set protocols bgp group TEST local-address 200.200.200.2
set protocols bgp group TEST import REJECT
set protocols bgp group TEST export ADVERTISED
set protocols bgp group TEST peer-as 65000
set protocols bgp group TEST neighbor 200.200.200.1 preference 20
set protocols ospf rib-group STAGING-RIB
set protocols ospf export BGP-to-OSPF
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 priority 150
set protocols ospf area 0.0.0.0 interface lo0.0 passive

SW-2-Konfigurationen

root@SW-2> show configuration interfaces | display set 
set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.2/30
set interfaces ge-0/0/1 unit 0 family ethernet-switching port-mode access
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members VLAN-254
set interfaces ge-0/0/11 description "Uplink to STAGING"
set interfaces ge-0/0/11 unit 0 family inet filter input FBF-TEST
set interfaces ge-0/0/11 unit 0 family inet address 10.100.100.1/30
set interfaces lo0 unit 0 family inet address 10.100.199.2/32
set interfaces vlan unit 2 family inet address 10.100.2.1/24
set interfaces vlan unit 251 family inet address 10.100.251.1/24
set interfaces vlan unit 254 family inet address 10.100.254.1/24

root@SW-2> show configuration routing-options | display set 
set routing-options nonstop-routing
set routing-options interface-routes rib-group inet STAGING-RIB
set routing-options static route 172.22.128.0/21 next-hop 10.22.76.1
set routing-options static route 10.22.20.0/24 next-hop 10.22.76.1
set routing-options static route 10.100.190.0/24 next-hop 10.100.100.2
set routing-options static route 10.100.191.0/24 next-hop 10.100.100.2
set routing-options rib-groups STAGING-RIB import-rib inet.0
set routing-options rib-groups STAGING-RIB import-rib PATH-1.inet.0
set routing-options rib-groups STAGING-RIB import-rib PATH-2.inet.0
set routing-options router-id 10.100.254.1

root@SW-2> show configuration routing-instances | display set  
set routing-instances PATH-1 instance-type forwarding
set routing-instances PATH-1 routing-options static route 10.100.30.0/24 next-hop 10.100.254.2
set routing-instances PATH-1 routing-options static route 10.100.30.0/24 qualified-next-hop 10.10.10.1 preference 100
set routing-instances PATH-2 instance-type forwarding
set routing-instances PATH-2 routing-options static route 10.100.30.0/24 next-hop 10.10.10.1
set routing-instances PATH-2 routing-options static route 10.100.30.0/24 qualified-next-hop 10.100.254.2 preference 100

root@SW-2> show configuration firewall | display set             
set firewall family inet filter FBF-TEST term TERM-1 from source-address 10.100.190.0/24
set firewall family inet filter FBF-TEST term TERM-1 from source-address 10.100.191.0/24
set firewall family inet filter FBF-TEST term TERM-1 then routing-instance PATH-1
set firewall family inet filter FBF-TEST term DEFAULT then routing-instance PATH-2

root@SW-2> show configuration protocols | display set   
set protocols ospf export ADVERTISED
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface vlan.2 passive
set protocols ospf area 0.0.0.0 interface vlan.251 passive
set protocols ospf area 0.0.0.0 interface vlan.254 priority 250

Könnten Sie die FBF-Test-ACL einschließen, meine Vermutung ist, dass Sie die IP-Adresse von SW2 nicht ausschließen oder Sie intern generierten Verkehr des Routers
einschließen

Die ACL ist enthalten. Suchen Sie nach der Zeile "show configuration firewall".
NetEng76

Können Sie die Schnittstellenkonfigurationen einbeziehen?
user2697

Ich habe die Schnittstellenkonfigurationen zum ursprünglichen Beitrag oben hinzugefügt.
NetEng76

Sollte Ihr Filter am Ende jedes Terms keine "Dann akzeptieren" -Zeile haben? Wird es sonst keinen unübertroffenen Verkehr fallen lassen?
SpacemanSpiff

Antworten:


4

Nachdem ich gestern mit JTAC gearbeitet hatte, brauchte "I", wie in "JTAC" wirklich nicht, da ich das Problem selbst herausgefunden hatte. Ich erkannte, dass mein Firewall-Filter etwas redundant war und keine "allow any" -Anweisung fehlte .

Die OSPF-Adjazenz wurde unterbrochen, weil der Firewall-Filter den "else" -Verkehr (Begriff DEFAULT) an die Routing-Instanz PATH-2 weiterleitete, was in keiner Weise hilfreich war, da er den Datenverkehr direkt zurück an SW-2 sendete Eine "dann akzeptieren" -Anweisung wäre leicht möglich gewesen

Also, um das Problem zu beheben ..

Neue SW-2 & RTR-2 korrigierte Konfigurationen:

delete routing-instances PATH-2
delete firewall family inet filter FBF-TEST term DEFAULT
set firewall family inet filter FBF-TEST term PERMIT-ANY then accept

Neue Konfigurations-Snips für SW-2:

routing-options {
    nonstop-routing;
    interface-routes {
        rib-group inet STAGING-RIB;
    }
    static {
        route 10.100.190.0/24 next-hop 10.100.100.2;
        route 10.100.191.0/24 next-hop 10.100.100.2;
    }
    rib-groups {
        STAGING-RIB {
            import-rib [ inet.0 PATH-1.inet.0 ];
        }
    }
    router-id 10.100.254.1;
}
firewall {
    family inet {
        filter FBF-TEST {
            term TERM-1 {
                from {
                    source-address {
                        10.100.190.0/24;
                        10.100.191.0/24;
                    }
                }
                then {
                    routing-instance PATH-1;
                }
            }
            term PERMIT-ANY {
                then accept;
            }
        }
    }
}
routing-instances {
    PATH-1 {
        instance-type forwarding;
        routing-options {
            static {
                route 10.100.30.0/24 {
                    next-hop 10.100.254.2;
                    qualified-next-hop 10.10.10.1 {
                        preference 100;
                    }
                }
            }
        }
    }
}

Neue Konfigurations-Snips für RTR-2:

routing-options {
    interface-routes {
        rib-group inet STAGING-RIB;
    }
    rib-groups {
        STAGING-RIB {
            import-rib [ inet.0 PATH-1.inet.0 ];
        }
    }
    router-id 200.200.200.2;
    autonomous-system 1;
}
firewall {
    family inet {
        filter FBF-TEST {
            term TERM-1 {
                from {
                    source-address {
                        10.100.190.0/24;
                        10.100.191.0/24;
                    }
                }
                then {
                    routing-instance PATH-1;
                }
            }
            term PERMIT-ANY {
                then accept;
            }
        }
    }
}
routing-instances {
    PATH-1 {
        instance-type forwarding;
        routing-options {
            static {
                route 10.100.30.0/24 {
                    next-hop 200.200.200.1;
                    qualified-next-hop 10.100.254.1 {
                        preference 100;
                    }
                }
            }
        }
    }
}
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.