Exemplo de configuração da Cisco para roteamento baseado em políticas

Eu me encontro em uma situação em que estive há não muito tempo atrás, mas não me lembro de como resolvi isso :)

O cenário

Eu tenho um roteador Cisco IOS com uma interface LAN (fa0 / 0) e uma interface WAN (fa0 / 1) e a segunda interface WAN (fa0 / 2).

• Existem duas subinterfaces LAN fa0 / 0.10 e fa0 / 0.20, digamos.
• Existe uma rota padrão via fa0 / 1. No entanto, existe uma rota estática para uma sub-rede específica, digamos 1.2.3.4/24 via fa0 / 2 (fa0 / 2 está mais próxima dessa sub-rede, mas um link WAN $$$ mais caro)

Todos os meus usuários fa0 / 0.10 estão acessando o 1.2.3.4/24 e, portanto, a rota estática os envia para fa0 / 2 (WAN2). Para todos os outros destinos, os usuários fa0 / 0.10 seguem a rota padrão do DHCP que recebo na interface WAN1 fa0 / 1.

A definição do problema;

Usuários na sub-rede fa0 / 0,20 acessam a Internet. Nenhum usuário da minha sub-rede fa0 / 0,20 realmente precisa acessar a sub-rede 1.2.3.4/24 remota. Raramente, porém, nesse caso, a rota estática os envia via fa0 / 2. Mas não quero isso, quero que eles acessem 1.2.3.4/24 via fa0 / 1, a interface WAN padrão. Acredito que posso conseguir isso via PBR, mas não consigo fazê-lo funcionar?

Esta é a configuração que estou tentando no momento;

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

Estou tentando aplicar o roteamento baseado em diretivas diretamente à sub-interface fa0 / 0.20 para forçar todo o tráfego via WAN1, fa0 / 1. Meu entendimento é que, como existe uma rota mais específica do que a rota padrão recebida pelo DHCP no fa0 / 1 no FIB, ele substitui o PBR e o tráfego de fa0 / 0.20 a 1.2.3.4/24 ainda está usando a WAN2, fa0 / 2) Ou pelo menos, acredito que esse seja o caso ao usar "definir interface padrão ...". Se eu usasse "set ip next-hop", por exemplo, isso forçaria o PBR a ter precedência, mas a WAN1, fa0 / 1, recebe um IP pelo DHCP e, portanto, está mudando :)

Como uma nota rodapé; Na verdade, existem muitas rotas estáticas via WAN2, portanto, não quero reverter a situação e a rota de política fa0 / 0.10 via WAN2 para sub-redes específicas. A configuração é mais complexa do que eu deixei transparecer, apesar de longa e curta, não é viável mudar isso. Além disso, se houver uma maneira melhor de resolver esse problema que não seja o PBR, sou todo ouvidos. Eu estou lutando com esse método porque é a melhor solução que eu conheço.

Atualização Adicionado um diagrama de topologia espetacularmente desenhado

Eu recomendaria usar um mapa de rotas para apenas um propósito (um para nat e outro para pbr); o uso misto pode causar confusão. Para o NAT, match interfaceserá aplicado o pós-roteamento - útil para fazer entradas nat condicionais.

O mapa de rotas para o PBR deve usar uma ACL para corresponder ao tráfego proveniente da LAN2 e, em seguida, definir o próximo salto para a interface desejada com set interfacenão set default- ou set ip next-hop dynamic dhcpcomo você não saberá o endereço GW real. Isso ignora / substitui qualquer lógica de roteamento que, de outra forma, enviaria tráfego para sua WAN cara.