Limitação de roteamento baseada em políticas do Cisco 3750?

Question

Eu tenho dois 3750s que são roteados via SVIs para sub-redes de servidores (Core1 e Core2, respectivamente). No Core1 eu tenho o vlan 1100 que tem um SVI de x.x.100.1 com um proxy de squid transparente em 100.3.

Quando faço o seguinte no core1:

ip access-list extended lab-filter
 remark ### Force HTTP and HTTPS to Barracuda ###
 deny tcp any any neq www 443
 deny ip any x.x.x.x 0.0.255.255
 permit ip x.x.x.x. 0.0.0.255 any

route-map Barracuda permit 20
 match ip address lab-filter
 set ip next-hop x.x.100.3

interface Vlan1100
description Barracuda VLAN Interface
ip address x.x.100.1 255.255.255.0
no ip redirects
no ip proxy-arp

On Core1
interface Vlan1010
ip address x.x.10.1 255.255.255.0
ip access-group 115 in
ip access-group 116 out
no ip redirects
no ip proxy-arp
ip policy route-map Barracuda

On Core2
interface Vlan1120
ip address x.x.120.1 255.255.255.0
ip access-group 102 in
no ip proxy-arp
ip policy route-map Barracuda

Tudo funciona bem, todo o tráfego da web é transferido para o filtro.

A pergunta vem quando eu tenho o outro 3750 que está diretamente conectado ao Core1 e tente a mesma coisa que ele não redireciona o tráfego para 100.3.

core1#sho route-map
route-map Barracuda, permit, sequence 20
  Match clauses:
    ip address (access-lists): lab-filter
  Set clauses:
    ip next-hop x.x.100.3
  Policy routing matches: 138260 packets, 12930735 bytes


core2#sho route-map
route-map Barracuda, permit, sequence 10
  Match clauses:
   ip address (access-lists): lab-filter
  Set clauses:
   ip next-hop x.x.100.3
  Nexthop tracking current: 0.0.0.0
  x.x.100.3, fib_nh:0,oce:0,status:0 
  Policy routing matches: 0 packets, 0 bytes

Basicamente eu estou tentando tirar tudo da vlan 1010 no Core1 e vlan 1120 do Core2 e redirecionar a porta 80 e 443 para a 100.3 que está diretamente conectada ao Core1.

O IP do próximo salto tem que ser uma rota conectada, e se não como eu posso passar isso?

    

Answer 1

O próximo salto deve ser o próximo endereço da camada 3 pelo qual o tráfego será passado, portanto, sim, ele deve estar em um segmento de rede que esteja diretamente conectado ao 3750 e tenha uma rota conectada.

Tenha em mente que você não está reescrevendo o endereço de destino do pacote, você está apenas roteando-o de uma maneira diferente. Assim, o próximo salto da camada 3 deve ser o Barracuda (quando seu roteador toca diretamente na vlan que o Barracuda está ligado), ou então um roteador de camada 3 do próximo salto que também esteja ciente (via roteamento baseado em política, provavelmente) de onde o tráfego precisa acabar.

    

Answer 2

A resposta de Shane sobre o próximo salto está correta, mas quero destacar outro problema. Você atualmente tem negar ACEs em sua ACL de correspondência. Ao usar o PBR em um 3750, você não deve negar o ACE em suas ACLs de correspondência. O 3750 faz o PBR no TCAM mas não pode fazê-lo para denys. O Denys será roteado pela CPU e poderá rapidamente eliminar o desempenho no seu switch. referência

Como você está fazendo o PBR, é necessário ter o conjunto de recursos dos serviços IP, você pode considerar o uso do WCCP no 3750. Tem algumas vantagens.

• Se o seu proxy falhar, o roteador não tente enviar tráfego para ele e irá encaminhar o tráfego normalmente permitindo que o acesso à Internet continue ininterrupto. (Dependendo do porquê você está proxying isso pode ou não seja o comportamento que você quer.)
• Você pode adicionar proxies adicionais para redundância.

Tenha em mente que o WCCP no 3750 redireciona e retorna o L2. Muitos dos guias para configurar o Squid e o WCCP são baseados no redirecionamento do GRE.