Verificación de disponibilidad de Cisco PBR con interfaz en lugar del siguiente salto

7

Tenemos una serie de enrutadores Cisco 891 configurados con enlaces WAN duales. Todos estos enrutadores están ejecutando Cisco IOS 15.x En algunos casos, usamos enrutamiento basado en políticas para forzar el tráfico particular por un enlace.

Utilizo mucho PBR con configuraciones de WAN dual, ya que el cliente generalmente quiere que cierto tráfico pase por un enlace en particular. Por ejemplo, a menudo necesitaré que el tráfico en tiempo real, como VOIP, pase por un enlace, luego Internet general para pasar por otro, y normalmente usaré PBR para enrutar el tráfico de acuerdo con la IP de origen / destino, VLAN o lo que sea apropiado .

Obviamente, es mejor seguir ofreciendo un servicio degradado si el enlace de voz dedicado se desconecta. Tiendo a usarlo set next-hop verify-availabilitycon un objeto de seguimiento de IP SLA para permitir que el tráfico continúe a la otra WAN, en caso de que sea necesario.

Mi pregunta es: ¿es posible hacer la misma configuración (con un objeto de seguimiento para verificar la disponibilidad) al usar PBR para configurar una interfaz, en lugar de un siguiente salto?

Hay un par de razones para esto:

  • Negociamos automáticamente la configuración de IP y enrutamiento en toda nuestra interfaz PPPoE Dialer. Uno de nuestros ISP de terceros siguió adelante y cambió la ruta predeterminada para todas sus conexiones DSL. Esto significaba que, dado que había codificado el siguiente salto en la configuración PBR, dejó de funcionar. Afortunadamente, el PBR falló a la otra WAN, pero en cualquier caso, he estado buscando evitar la dependencia de codificar la IP siempre que pueda, de forma similar a cómo hago las rutas predeterminadas:ip route 0.0.0.0 0.0.0.0 Dialer0 10 track 1

  • Hoy me han pedido que configure WAN duales en algún CPE nuevo, e iba a usar PBR para forzar nuestro tráfico de VOIP por una línea dedicada, fallando de nuevo al enlace de Internet si es necesario. El problema es que este cliente está utilizando dos líneas DSL del mismo ISP, por lo que el siguiente salto sería el mismo en ambos casos. Obviamente, lo que haré a continuación es configurar la interfaz, pero esto significa que pierdo mi verificación de disponibilidad.

Esperando que alguien sepa qué configuración de PBR puedo usar para lograr esto al configurar las interfaces.

Como referencia, así es como lo hago actualmente, con next-hop:

EDITAR: Incluye un ejemplo más detallado.

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
!
cisco  routing  router  cisco-ios-15  pppoe 
— Geekman
fuente
Ayúdame a comprender la necesidad exacta de PBR ... ¿es para seleccionar una ruta basada en la fuente-ip, o simplemente como una herramienta para asegurar que el proveedor ADSL esté disponible?
— Mike Pennington
@ Mike lo uso para enrutar el tráfico (aunque no siempre por IP de origen). En la mayoría de los casos, tendré un tipo específico de tráfico (como VOIP) que deseo enrutar principalmente a un enlace en particular, pero conmutar por error al otro enlace si el principal se desconecta. Espero que sea más claro.
— Geekman
@ Mike agregó algunos detalles sobre el uso de PBR a la pregunta.
— Geekman
Tengo curiosidad, ¿estás usando dos enlaces ADSL con interfaces Dialer? Si no, ¿qué estás usando para el otro enlace? ¿El marcador siempre está activo o se dispara por el tráfico?
— Mike Pennington
@ MikePennington Varía, pero sí, generalmente hay al menos un enlace DSL. Pero incluso en el caso de que el cliente esté usando Fiber / EFM, no puedo confiar exactamente en que la interfaz se caiga, ya que la NTU puede estar bien dejando la interfaz activa, pero aún podemos dejar de pasar el tráfico. Publicaré una configuración más completa en breve.
— Geekman

Respuestas:

3

Como se discutió en el chat, el tráfico PBX / SIP es exclusivo de una ruta de host IP en su caso. Por lo tanto, puede eliminar PBR y usar objetos de seguimiento en rutas estáticas superpuestas, que salen de diferentes dialerinterfaces para resolver el 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
— Mike Pennington
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.