JUNIPER: Dlaczego przyleganie OSPF przerywa się, gdy włączam FBF na interfejsie OSPF?


9

Zbudowałem laboratorium testowe, w którym testuję przekazywanie oparte na filtrach (FBF), znane również jako routing oparty na zasadach. Pytanie zostanie przedstawione poniżej, ale najpierw szczegóły:

Poniżej znajduje się schemat topologii:

wprowadź opis zdjęcia tutaj

CEL: Każdy ruch przeznaczony do przemieszczania z lokalizacji 1 powinien być kierowany przez łącze 2 do sieci WAN, a NIE przez łącze 1. Ponieważ łącze 1 będzie nasycone ruchem replikacji między dwoma centrami danych.

  • SW-1 i SW-2 to przełączniki Juniper EX4200
  • RTR-1 i RTR-2 to Juniper J4350
  • PE-1 i PE-2 to routery Cisco 1841 z ISIS i MPLS VPN do symulacji szkieletu sieci WAN dostawcy

SW-1, SW-2, RTR-1 i RTR-2 są sąsiadami OSPF w Obszarze 0. Zarówno RTR-1, jak i RTR-2 są ASBR i wstrzykują trasy OSPF do OSPF. Każdy router reklamuje trasy do sieci WAN dla swojej odpowiedniej strony (a także wcześniej przygotowane trasy dla drugiej strony w celu uzyskania nadmiarowości).

Przekierowywanie ruchu z witryny 1 do przemieszczania w ośrodku 2 jest łatwe do zrealizowania, po prostu poprzez redystrybucję statycznej trasy do przemieszczania na SW-2 do OSPF z wyższą miarą. Ponieważ ta trasa jest reklamowana przez RTR-2 w sieci WAN, RTR-1 nauczy się tej trasy i rozprowadzi ją do OSPF z metryką 0. Trasa OSPF wyuczona na SW-1 z SW-2 miałaby wyższą metrykę, a zatem routing byłby lepszy niż sieć WAN.

Ruch powrotny z ośrodka 2 również musi przepływać w ten sposób, aby uniknąć routingu asymetrycznego. FBF jest stosowany na interfejsie wejściowym (Link 4), wprowadzając SW-2. Ten filtr pobierze cały ruch pochodzący ze stopniowania (10.100.190 / 24) i wykona RTR-2 następnego skoku. Ta część FBF działa, jak przetestowałem w laboratorium.

Ponieważ preferowaną drogą powrotną RTR-2 do strony 1 jest Link 1, musimy ponownie zastosować FBF na wejściowym interfejsie LAN RTR-2 (przodem do SW-2).

Oto problem ... Kiedy FBF jest zastosowany na tym routerze, przyleganie OSPF do SW-2 zostaje zerwane.

PYTANIE: Dlaczego sąsiedztwo OSPF przełamuje RTR-2 i SW-2?

Załączono konfigurację dla RTR-2 i SW-2:

RTR-2 Configs

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

Konfiguracje SW-2

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

czy możesz dołączyć testową listę ACL FBF, zgaduję, że nie wykluczasz adresu IP SW2 lub
włączasz

ACL jest wliczony w cenę. Poszukaj linii „pokaż konfigurację zapory ogniowej”.
NetEng76

Czy możesz dołączyć konfiguracje interfejsu?
user2697,

Dodałem konfiguracje interfejsu do powyższego oryginalnego postu.
NetEng76

Czy twój filtr nie powinien zawierać wiersza „następnie zaakceptuj” na końcu każdego terminu? Czy inaczej nie spowoduje żadnego niedopasowanego ruchu?
SpacemanSpiff,

Odpowiedzi:


4

Więc po wczorajszej pracy z JTAC, „ja”, ponieważ tak naprawdę nie potrzebowałem JTAC, ponieważ sam odkryłem problem. Zdałem sobie sprawę, że mój filtr zapory sieciowej jest nieco redundantny i brakuje mu instrukcji „zezwól na jakiekolwiek” .

Przyleganie OSPF pękało, ponieważ filtr zapory przejmował ruch „else” (termin DOMYŚLNY) i wysyłał go do PATH-2 instancji routingu, co nie pomogło, ponieważ wysyłało ruch z powrotem do SW-2, coś oświadczenie „następnie zaakceptuj” byłoby łatwe

Aby naprawić problem ...

Nowe konfiguracje z poprawkami SW-2 i RTR-2:

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

Nowe wycinki konfiguracji dla 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;
                    }
                }
            }
        }
    }
}

Nowe wycinki konfiguracji dla 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;
                    }
                }
            }
        }
    }
}
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.