J'ai construit un laboratoire de test où je teste le Filter Based Forwarding (FBF), alias Policy Based Routing. La question suivra ci-dessous, mais d'abord, les détails:
Voici le diagramme de topologie:
OBJECTIF: Tout trafic destiné au transfert depuis le site 1 doit être acheminé via le lien 2 vers le WAN et non via le lien 1. Le lien 1 étant saturé de trafic de réplication entre les deux centres de données.
- SW-1 et SW-2 sont des commutateurs Juniper EX4200
- RTR-1 et RTR-2 sont des Juniper J4350
- PE-1 et PE-2 sont des routeurs Cisco 1841 exécutant ISIS et MPLS VPN pour simuler la dorsale WAN du fournisseur
SW-1, SW-2, RTR-1 et RTR-2 sont tous des voisins OSPF dans la zone 0. RTR-1 et RTR-2 sont des ASBR et injectent des routes apprises BGP dans OSPF. Chaque routeur publie des routes dans le WAN pour son site respectif (ainsi que des routes pré-suspendues pour l'autre site à des fins de redondance).
Le routage du trafic du site 1 vers le transfert sur le site 2 est facilement accompli en redistribuant simplement la route statique vers le transfert sur SW-2 dans OSPF avec une métrique plus élevée. Puisque cet itinéraire est annoncé par RTR-2 dans le WAN, RTR-1 apprendra cet itinéraire et le redistribuera dans OSPF avec une métrique de 0. La route OSPF apprise sur SW-1 à partir de SW-2 aurait une métrique plus élevée, ainsi le routage serait préféré au WAN.
Le trafic de retour du site 2 doit également s'écouler de cette façon afin d'éviter le routage asymétrique. FBF est appliqué sur l'interface entrante (lien 4) entrant dans SW-2. Ce filtre prendra tout le trafic provenant de Staging (10.100.190 / 24) et fera le RTR-2 du prochain saut. Cette partie du FBF fonctionne, comme je l'ai testé en laboratoire.
Étant donné que l'itinéraire préféré de RTR-2 pour revenir au site 1 se fait via le lien 1, nous devons appliquer FBF à nouveau à l'interface LAN entrante de RTR-2 (face à SW-2).
Voici le problème ... Lorsque FBF est appliqué sur ce routeur, la contiguïté OSPF avec SW-2 se casse.
QUESTION: Pourquoi la contiguïté OSPF rompt-elle entre RTR-2 et SW-2 ??
La configuration pour RTR-2 et SW-2 est jointe:
Configurations RTR-2
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
Configurations 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
Réponses:
Donc, après avoir travaillé avec JTAC hier, "je", comme dans je n'avais vraiment pas besoin de JTAC depuis que j'ai résolu le problème par moi-même .. réalisé que mon filtre pare-feu était un peu redondant et qu'il manquait une déclaration "autoriser tout" .
La contiguïté OSPF se brisait parce que le filtre du pare-feu prenait le trafic «else» (terme DEFAULT) et l'envoyait à l'instance de routage PATH-2, ce qui n'a pas aidé dans les deux sens car il renvoyait le trafic directement à SW-2, quelque chose une déclaration "puis accepter" aurait fait facilement
Donc, pour réparer le problème ..
Nouvelles configurations corrigées SW-2 et RTR-2:
Nouvelles coupures de configuration pour SW-2:
Nouvelles coupures de configuration pour RTR-2:
la source