Przykład konfiguracji Cisco dla routingu opartego na zasadach

Ja odnajduję się w sytuacji, w której byłem nie tak dawno temu, ale nie pamiętam, jak to rozwiązałem :)

Scenariusz

Mam router Cisco IOS z interfejsem LAN (fa0 / 0) i interfejsem WAN (fa0 / 1) oraz drugim interfejsem WAN (fa0 / 2).

• Istnieją dwa pod-interfejsy LAN fa0 / 0.10 i powiedzmy fa0 / 0.20.
• Istnieje domyślna trasa przez fa0 / 1. Istnieje jednak statyczna droga do określonej podsieci, powiedzmy 1.2.3.4/24 przez fa0 / 2 (fa0 / 2 jest bliżej tej podsieci, ale droższe łącze WAN $$$)

Wszyscy moi użytkownicy fa0 / 0.10 uzyskują dostęp do 1.2.3.4/24, więc trasa statyczna wysyła ich z fa0 / 2 (WAN2). Do wszystkich innych miejsc docelowych użytkownicy fa0 / 0.10 przechodzą domyślną trasą DHCP, którą odbieram na interfejsie WAN1 fa0 / 1.

Definicja problemu;

Użytkownicy w podsieci fa0 / 0.20 po prostu uzyskują dostęp do Internetu. Żaden użytkownik w mojej podsieci fa0 / 0.20 nie ma potrzeby dostępu do zdalnej podsieci 1.2.3.4/24. Rzadko to robią, w takim przypadku trasa statyczna wysyła je za pośrednictwem fa0 / 2. Nie chcę tego jednak, chcę, aby mieli dostęp do 1.2.3.4/24 przez fa0 / 1, domyślny interfejs WAN. Wierzę, że mogę to osiągnąć za pomocą PBR, ale wydaje mi się, że nie mogę tego uruchomić?

To jest konfiguracja, którą próbuję obecnie;

interface FastEthernet0/0.10
 description LAN1
 encapsulation dot1Q 10
 ip address 192.168.10.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly

interface FastEthernet0/0.20
 description LAN2
 encapsulation dot1Q 20
 ip address 192.168.20.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
 ip policy route-map FORCE-LAN2-VIA-WAN1

interface FastEthernet0/1
 description WAN1
 ip address dhcp
 ip nat outside
 ip virtual-reassembly

interface FastEthernet0/2
 description WAN2 - Used for 1.2.3.4/24
 ip address 5.5.5.5 255.255.255.0

! Static route to route to a remote subnet via 2nd WAN link
ip route 1.2.3.4 0.0.0.255 5.5.5.6
! A default route is received on fa0/1 (WAN1) via DHCP from ISP
! for all other traffic
!
! NAT fa0/0.10 users when accessing the Internet via WAN1
ip nat inside source route-map ROUTE-WAN1 interface FastEthernet0/1 overload
!
! NAT fa0/0.20 users out via WAN1
ip nat inside source route-map FORCE-LAN2-VIA-WAN1 interface FastEthernet0/1 overload

route-map ROUTE-WAN1 permit 10
 match interface FastEthernet0/1

route-map FORCE-LAN2-VIA-WAN1 permit 10
 match interface FastEthernet0/0.20
 set default interface FastEthernet0/1

Usiłuję zastosować routing oparty na regułach bezpośrednio do pod-interfejsu fa0 / 0.20, aby wymusić cały ruch przez WAN1, fa0 / 1. Rozumiem, że ponieważ istnieje bardziej konkretna trasa niż domyślna trasa odebrana przez DHCP na fa0 / 1 w FIB, zastępuje PBR, a ruch z fa0 / 0.20 do 1.2.3.4/24 nadal używa WAN2, fa0 / 2) A przynajmniej uważam, że tak jest w przypadku korzystania z „ustaw domyślny interfejs ...”. Gdybym na przykład użył opcji „ustaw ip następnego przeskoku”, wymusiłoby to na PBR pierwszeństwo, ale WAN1, fa0 / 1, otrzymuje adres IP przez DHCP i dlatego się zmienia :)

Na marginesie; W rzeczywistości istnieje wiele tras statycznych przez WAN2, więc nie chcę odwracać sytuacji i trasy polityki fa0 / 0.10 przez WAN2 dla określonych podsieci. Konfiguracja tam jest bardziej złożona niż na to pozwoliłem, choć jest ona długa i krótka, nie można tego zmienić. Dodatkowo, jeśli istnieje lepszy sposób na rozwiązanie tego problemu niż PBR, jestem cały w uszach. Walczę tą metodą, ponieważ jest to najlepsze rozwiązanie, jakie znam.

Aktualizacja Dodano spektakularnie narysowany diagram topologii

Poleciłbym używać mapy tras tylko do jednego celu (jeden dla nat, drugi dla pbr); mieszane użycie może spowodować bałagan. W przypadku NAT, match interfacezastosuje się po routingu - przydatne, aby wprowadzić warunkowe wpisy nat.

Mapa tras dla PBR powinna używać listy ACL, aby dopasować ruch przychodzący z LAN2, a następnie ustawić następny przeskok do żądanego interfejsu z set interfacenie set default- lub set ip next-hop dynamic dhcpponieważ nie będziesz znać rzeczywistego adresu gw. To omija / zastępuje wszelką logikę routingu, która w przeciwnym razie wysyłałaby ruch do drogiej sieci WAN.