Verificação de disponibilidade do Cisco PBR com interface em vez do salto seguinte


7

Temos um número de roteadores Cisco 891 configurados com links WAN duplos. Todos esses roteadores estão executando o Cisco IOS 15.x Em alguns casos, usamos o roteamento baseado em políticas para forçar o tráfego específico em um link.

Eu uso muito o PBR com configurações de WAN dupla, pois o cliente geralmente deseja que determinado tráfego passe por um link específico. Por exemplo, muitas vezes eu preciso que o tráfego em tempo real, como o VOIP, passe por um link, depois a Internet geral para outro, e normalmente usarei o PBR para rotear o tráfego de acordo com o IP de origem / destino, VLAN ou o que for adequado .

Obviamente, é melhor ainda oferecer um serviço degradado se o link de voz dedicado ficar offline. Costumo usar set next-hop verify-availabilitycom um objeto de rastreamento de SLA IP para permitir que o tráfego ainda faça failover na outra WAN, caso seja necessário.

Minha pergunta é: É possível fazer a mesma configuração (com um objeto de rastreamento para verificar a disponibilidade) ao usar o PBR para definir uma interface, em vez de um salto seguinte?

Há algumas razões para isso:

  • Negociamos automaticamente as configurações de IP e roteamento em toda a nossa interface do Discador PPPoE. Um de nossos ISPs de terceiros foi adiante e alterou a rota padrão para todas as suas conexões DSL. Isso significava que, desde que eu codifiquei o próximo salto na configuração do PBR, ele parou de funcionar. Felizmente, o PBR efetuou o failover para a outra WAN, mas, em qualquer caso, eu tenho procurado evitar a dependência de codificar o IP sempre que possível, semelhante à maneira como faço as rotas padrão:ip route 0.0.0.0 0.0.0.0 Dialer0 10 track 1

  • Hoje me pediram para configurar duas WANs em algum novo CPE e usaria o PBR para forçar nosso tráfego VOIP em uma linha dedicada, retornando ao link da Internet, se necessário. O problema é que esse cliente está usando duas linhas DSL do mesmo ISP e, portanto, o próximo salto seria o mesmo nos dois casos. Então, obviamente, o que farei em seguida é definir a interface, mas isso significa que eu perco minha disponibilidade de verificação.

Esperando que alguém saiba qual configuração de PBR posso usar para conseguir isso ao definir interfaces.

Para referência, veja como faço atualmente, com next-hop:

EDIT: Incluído exemplo mais detalhado.

track 1 ip sla 1
 delay down 20 up 10
!
track 2 ip sla 2
 delay down 20 up 10
!

interface FastEthernet8
 description PPPoE ADSL2+ VOIP
 no ip address
 ip nat outside
 ip virtual-reassembly in
 duplex auto
 speed auto
 pppoe enable group global
 pppoe-client dial-pool-number 1

interface GigabitEthernet0
 description PPPoE ADSL2+ All Internet Traffic
 no ip address
 ip nat outside
 ip virtual-reassembly in
 duplex auto
 speed auto
 pppoe enable group global
 pppoe-client dial-pool-number 2

interface Vlan1
 description $ETH_LAN$
 ip address 192.168.1.254 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 ip tcp adjust-mss 1452
 ip policy route-map PBR-LAN

interface Dialer0
 description VOIP ADSL2+ Dialer Interface
 bandwidth 1024
 bandwidth receive 20480
 ip address negotiated
 no ip redirects
 no ip proxy-arp
 ip mtu 1492
 ip nat outside
 ip virtual-reassembly in
 encapsulation ppp
 ip tcp adjust-mss 1452
 dialer pool 1
 dialer-group 1
 ppp authentication chap pap callin
 ppp chap hostname xxxx@cust.example.com
 ppp chap password 0 yyyy
 ppp pap sent-username xxxx@cust.example.com password 0 yyyy
 no cdp enable

interface Dialer1
 description Internet ADSL2+ Dialer Interface
 bandwidth 1024
 bandwidth receive 20480
 ip address negotiated
 no ip redirects
 no ip proxy-arp
 ip mtu 1492
 ip nat outside
 ip virtual-reassembly in
 encapsulation ppp
 ip tcp adjust-mss 1452
 dialer pool 2
 dialer-group 2
 ppp authentication chap pap callin
 ppp chap hostname zzz@cust2.example.com
 ppp chap password 0 aaa
 ppp pap sent-username zzz@cust2.example.com password 0 aaa
 no cdp enable

ip local policy route-map PBR-LOCAL
ip nat inside source route-map DSL2-DATA-NAT interface Dialer1 overload
ip nat inside source route-map DSL2-VOIP-NAT interface Dialer0 overload
ip route 0.0.0.0 0.0.0.0 Dialer0 10 track 1
ip route 0.0.0.0 0.0.0.0 Dialer1 track 2


ip access-list extended NAT-POOL
 remark Be sure to exclude remote LANs in this ACL
 deny   ip 192.168.1.0 0.0.0.255 192.168.7.0 0.0.0.255
 permit ip 192.168.1.0 0.0.0.255 any
ip access-list extended PBR-DSL-DATA
 remark Match local traffic with DSL DATA src IP
 permit ip host 89.123.45.67 any
ip access-list extended PBR-DSL-VOIP
 remark Match local traffic with DSL VOIP src IP
 permit ip host 89.123.45.70 any
ip access-list extended VOIP-PBX
 remark Match traffic to/from our VOIP PBX so it can use dedicated link.
 permit ip host 89.123.45.10 any
 permit ip any host 89.123.45.10

! For the IP SLAs I simply ping the gateway of the circuit
! In this case, we have two DSL links from the same ISP
! So I simply ping the same gateway for both, with different source interfaces.
ip sla 1
 icmp-echo 89.123.45.1 source-interface Dialer0
 threshold 4000
 frequency 5
ip sla schedule 1 life forever start-time now
ip sla 2
 icmp-echo 89.123.45.1 source-interface Dialer1
 threshold 4000
 frequency 5
ip sla schedule 2 life forever start-time now

! These PBR-LOCAL route-maps are used for traffic coming from
! The router itself. (eg. ICMP, IPSec) Allows it to correctly
! Respond on both links, no matter which is the primary/active link.
route-map PBR-LOCAL permit 10
 description Route traffic with src IP VOIP DSL
 match ip address PBR-DSL-VOIP
 set interface Dialer0
!
route-map PBR-LOCAL permit 20
 description Route traffic with src IP DATA DSL
 match ip address PBR-DSL-DATA
 set interface Dialer1
!

route-map PBR-LAN permit 1
 description This route map is to match all VOIP traffic and force it over the correct ADSL line
 match ip address VOIP-PBX
 ! Using next-hop is how I would typically do this sort of thing.
 ! However - in this case since both links are from the same ISP, the next-hop is the same in both cases.
 ! So, although I haven't tried it, I am sure the router would have no way to know exactly which link I mean.
 !
 ! In this example, I've used 89.123.45.1 as the gateway IP for both DSL links.
 !
 !
 ! Try using VOIP Link
 ! set ip next-hop verify-availability 89.123.45.1 1 track 1
 ! If that fails, try the DATA link
 ! set ip next-hop verify-availability 89.123.45.1 2 track 2
 !
 !
 ! Because of this, my work-around has been to simply specify the Dialer interface
 ! of the link I want to use. But this also means no failover to the data link.
 ! Hope this makes sense.
 !
 !
 set interface Dialer0


route-map DSL2-VOIP-NAT permit 10
 description This route match is to match NAT traffic for the VOIP ADSL2+ Connection
 match ip address NAT-POOL
 match interface Dialer0
!
route-map DSL2-DATA-NAT permit 10
 description This route match is to match NAT traffic for the DATA ADSL2+ Connection
 match ip address NAT-POOL
 match interface Dialer1
!

Ajude-me a entender a necessidade exata do PBR ... é selecionar uma rota com base no IP de origem ou apenas como uma ferramenta para garantir que o provedor ADSL esteja disponível?
Mike Pennington

@ Mike Eu o uso para rotear tráfego (embora nem sempre por IP de origem). Na maioria dos casos, terei um tipo específico de tráfego (como VOIP) que desejo encaminhar principalmente para um link específico, mas faça failover para o outro link se o principal ficar offline. Espero que seja mais claro.
91113 Geekman

@ Mike Adicionados alguns detalhes sobre o uso de PBR à pergunta.
91113 Geekman

Estou curioso, você está usando dois links ADSL com interfaces Dialer? Se não, o que você está usando para o outro link? O discador está sempre ativo ou é acionado pelo tráfego?
Mike Pennington

@ MikePennington Varia, mas sim, geralmente há pelo menos um link DSL. Mas, mesmo que o cliente esteja usando o Fiber / EFM, não posso confiar exatamente na queda da interface, pois o NTU pode estar bem ao deixar a interface ativa, mas ainda podemos parar de passar o tráfego. Vou postar uma configuração mais completa em breve.
101313 Geekman

Respostas:


3

Conforme discutido no bate-papo, o tráfego PBX / SIP é exclusivo para uma rota de host IP no seu caso. Portanto, você pode remover o PBR e usar objetos de rastreamento em rotas estáticas sobrepostas, que utilizam dialerinterfaces diferentes para resolver o problema.

ip route 89.123.45.10 255.255.255.255 Dial0 track 1 1 name PBX_Pri
ip route 89.123.45.10 255.255.255.255 Dial1 track 2 10 name PBX_Bak
ip route 0.0.0.0 0.0.0.0 Dial 1 track 2 1 name Data_Pri
ip route 0.0.0.0 0.0.0.0 Dial 0 track 1 10 name Data_Bak
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.