Назад | Перейти на главную страницу

Ограничение маршрутизации на основе политик Cisco 3750?

У меня есть два 3750, которые маршрутизируют через SVI для подсетей сервера (Core1 и Core2 соответственно). На Core1 у меня vlan 1100 с SVI x.x.100.1 с прозрачным прокси-сервером squid на 100.3.

Когда я делаю на 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

Все работает нормально, весь веб-трафик попадает в фильтр.

Вопрос возникает, когда у меня есть другой 3750, который напрямую подключен к Core1, и я пробую то же самое, что не перенаправляет трафик на 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

В основном я пытаюсь извлечь все из vlan 1010 на Core1 и vlan 1120 из Core2 и перенаправить порт 80 и 443 на 100.3, который напрямую подключен к Core1.

Должен ли IP-адрес следующего перехода быть подключенным маршрутом, и если нет, как я могу его передать?

Следующим шагом должен быть адрес следующего уровня 3, на который будет передаваться трафик, так что да, он должен быть в сегменте сети, который напрямую подключен к 3750 и имеет подключенный маршрут.

Имейте в виду, что вы не переписываете адрес назначения пакета, вы просто маршрутизируете его по-другому. Таким образом, следующим переходом уровня 3 должен быть либо Barracuda (когда ваш маршрутизатор напрямую касается vlan, который включен Barracuda), либо маршрутизатор следующего уровня 3, который также знает (через маршрутизацию на основе политик, вероятно) о том, где это трафик должен закончиться.

Ответ Шейна относительно следующего перехода правильный, но я хочу указать еще на одну проблему. В настоящий момент у вас есть запретить ACE в вашем матчевом ACL. При использовании PBR на 3750 у вас не должно быть запрещения ACE в ваших списках контроля доступа. 3750 выполняет PBR в TCAM, но не может этого сделать для denys. Denys будет перенаправлен на ЦП и может быстро снизить производительность вашего коммутатора. ссылка

Поскольку вы выполняете PBR, у вас должен быть набор функций IP-служб, вы можете вместо этого рассмотреть возможность использования WCCP на 3750. У него есть несколько преимуществ.

  • Если ваш прокси-сервер выходит из строя, маршрутизатор не будет пытаться отправить на него трафик и будет маршрутизировать трафик, как правило, позволяя доступу в Интернет продолжать непрерывно. (В зависимости от того, почему вы проксируете, это может быть, а может и не быть тем поведением, которое вы хотите.)
  • Вы можете добавить дополнительные прокси-серверы для резервирования.

Имейте в виду, что WCCP на 3750 выполняет перенаправление L2 и возвращает. Многие руководства по настройке Squid и WCCP основаны на перенаправлении GRE.