[GTER] 3750E - PBR

[Bruno Camargo]

Temos QoS implantado, fim a fim, porém em testes de uso Voz e video foram
impactados ao serem balanceados, talvez por adotarem caminhos diferentes no
IN e OUT.

MInha ideia agora é marcar as subnets de VOZ e VIDEO de todas as
localidades com uma community BGP, dar match na community e ajustar a
metrica na redistribuição para o IGP de forma a influenciar o tráfego
outbound. O tráfego inbound continuaria com o esquema de prepends.

O q acham ? Quero evitar dar match and endereços IP, pois qq mudança em uma
dada localidade desencadearia mudanças em todas as outras.

Abraco e obrigado!

2012/3/11 Andre Gustavo de C. Albuquerque <gustavo.albuquerque at gmail.com>

> Importante também mencionar que o balanceamento é normalmente feito por
> fluxo e não por pacote, especialmente em switches. Desta forma, não vejo
> motivo para o tráfego de voz ser impactado por balanceamento.
> Balanceamento por pacotes não encontra muito espaço nos dias de hoje. O
> design de rede deve prever formas de distribuir o tráfego entre múltiplos
> links, se o requisito dos múltiplos links for aumento de capacidade, e não
> redundância. Se o requisito for redundância, não faz sentido querer forçar
> o balanceamento, já que a implementação de QoS pode fazer com que os
> requisitos de SLA (delay, jitter, packet loss) fiquem dentro dos limites
> exigidos pela aplicação.
>
> Abs, Gustavo Albuquerque
>
> 2012/3/11 Andre Gustavo de C. Albuquerque <gustavo.albuquerque at gmail.com>
>
> > Bruno, bom dia.
> > A funcionalidade "PBR support for multiple track options" não está
> > disponível nesta plataforma.
> > Para ter uma lista completa de plataformas que a suportam, consulte o
> > Feature Navigator, a partir de http://www.cisco.com/go/cfn
> > Em switches, e em resumo, você pode encontrar essa funcionalidade em
> > Cat2960, Cat6500, e as linhas da Metro ME3400, ME3600X, ME3800X, ME4900 e
> > ME6524.
> > Existe uma comunidade de suporte para sistemas e soluções da Cisco, que
> > pode ser encontrada a partir de
> > https://supportforums.cisco.com/community/portuguese. Este canal pode
> ser
> > interessante para perguntas com foco tão específico.
> >
> > Abs, Gustavo Albuquerque
> >
> > 2012/3/10 Bruno Camargo <mustardahc at gmail.com>
> >
> >> Cara lista,
> >>
> >> Fiz um design de rede para um cliente que possui diversas localidades em
> >> uma rede MPLS. Todas elas possuem dois links e dois roteadores.
> >>
> >> O cliente quer usar ambos os links em load-share, porém não podemos
> >> balancear voip e video, pois ambos são impactados.
> >>
> >> Criei um esquema de Policy-based routing com verify-availability para
> >> forçar o tráfego outbound, aplicado no nosso switch core, e para o
> tráfego
> >> inbound estou "prependando" as subnets de voz e video no anuncio do BGP
> >> pela operadora.
> >>
> >> Hj estava, implementando o primeiro site, e o core switch é um stack de
> >> switches 3750 modelo WS-C3750E-48TD-E composto por 3 switches.
> >>
> >> O IOS é C3750E-UNIVERSALK9-M.
> >> Licensa é IPSERVICES.
> >> SDM PREFER ajustado para ROUTING.
> >>
> >> Porém o PBR não funcionava.
> >>
> >> Eis a config tentada:
> >>
> >> conf t
> >> ip access-list sta vcc-voice-via-primary
> >>  permit 10.148.8.0 0.0.0.255
> >>  permit 10.148.10.0 0.0.1.255
> >> ip route 152.187.100.232 255.255.255.252 gi1/0/1 10.148.148.2
> >> ip sla 1
> >>  icmp-echo 152.187.100.233 source-ip 10.148.148.1
> >>  timeout 1000
> >>  frequency 2
> >> ip sla schedule 1 start now life forever
> >> track 1 rtr 1 state
> >>  delay up 29
> >> route-map vcc-voice-via-primary permit 10
> >>  match ip address vcc-voice-via-primary
> >>  set ip next-hop verify-availability 10.148.148.2 1 track 1
> >> route-map vcc-voice-via-primary permit 200
> >> interface range vlan 8 , vlan 10
> >>  ip policy route-map vcc-voice-via-primary
> >> end
> >>
> >> Eis o LOG:
> >>
> >> Mar 10 20:05:09 CST: %PLATFORM_PBR-3-UNSUPPORTED_RMAP: Route-map
> >> vcc-voice-via-primary not supported for Policy-Based Routing
> >> Mar 10 20:08:02 CST: %PLATFORM_PBR-3-UNSUPPORTED_RMAP: Route-map
> >> vcc-voice-via-primary not supported for Policy-Based Routing
> >>
> >> Verificando a mensagem no site da cisco, temos o seguinte:
> >>
> >> Error Message    PLATFORM_PBR-3-UNSUPPORTED_RMAP: Route-map [chars]
> >> not supported for
> >> Policy-Based Routing
> >>
> >> Explanation    This message means that the route-map attached to an
> >> interface for policy routing contains an action that is not supported on
> >> this platform. This is a hardware limitation. [chars] is the route-map.
> >>
> >> Recommended Action    Reconfigure the route-map to use *permit* entries
> >> and
> >> *set ip next-hop* actions only.
> >>
> >> Alterei a config para:
> >>
> >> conf t
> >> !
> >> route-map vcc-voice-via-primary permit 10
> >>  set ip next-hop 10.148.148.2
> >> route-map vcc-voice-via-primary permit 200
> >> interface range vlan 8 , vlan 10
> >>  ip policy route-map vcc-voice-via-primary
> >> end
> >>
> >> E agora:
> >>
> >> Pittcoresw1#sh ip policy
> >> Interface      Route map
> >> Vlan8          vcc-voice-via-primary
> >> Vlan10         vcc-voice-via-primary
> >>
> >> Porem perco a funcionalidade de tracking, ou seja, se o link primario
> >> cair,
> >> o tráfego de voz e video bate no PBR é redirecionado para o router
> >> primario, que o devolve para o core switch, que finalmente o roteia via
> >> router secundario. Sem essa feature adicionamos um HOP ao trafego real
> >> time
> >> qdo o link primario cai. A performance nao é muito impactada, porem isso
> >> nao me deixa confortavel.
> >>
> >> Alguem sabe precisar se essa plataforma é realmente tão limitada em
> termos
> >> serviços layer 3 ou se eu estou comendo bola ?
> >>
> >> Valeu!
> >>
> >> --
> >> Bruno Camargo
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>
> >
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
Bruno Camargo