Сообщения без ответов | Активные темы Текущее время: 28 мар 2024, 20:27



Эта тема закрыта, вы не можете редактировать и оставлять сообщения в ней.  [ Сообщений: 16 ] 
PBR на С6509 
Автор Сообщение

Зарегистрирован: 18 ноя 2009, 20:20
Сообщения: 260
Дано:

Catalyst 6509, sup720.
множество маршрутизируемых виланов
дефолтный гейт - 10.100.100.100

10.200.200.200, 10.100.100.100 - directly connected

схема примерно такая:

Код:
  vlan_11
        |
    Catalyst_6509 - 10.100.100.100 ---- ISP
     |         \                        /
192.168.0.0/16   10.200.200.200 -------/


Необходимо:

для подсети 10.1.1.0/26 сделать дефолтный гейт 10.200.200.200

Пробовал:

route-map alt-def-GW permit 10
match ip address acl_from_net_10-1-1-0
match ip next-hop acl_defGW
set ip next-hop 10.200.200.200

ip access-list standard acl_defGW
permit 10.100.100.100

ip access-list extended acl_from_net_10-1-1-0
permit ip 10.1.1.0 0.0.0.63 any


int vlan 11
ip addr 10.1.1.1 255.255.255.192
ip policy route-map alt-def-GW
end

После указания команды ip policy route-map alt-def-GW трафик наглухо стопится...
Немогу понять где ошибся...


11 мар 2010, 14:20
Профиль WWW

Зарегистрирован: 29 ноя 2009, 23:07
Сообщения: 234
А железка маршрутизировать не умеет? Вроде простым маршрутом должно решаться


11 мар 2010, 14:38
Профиль

Зарегистрирован: 18 ноя 2009, 20:20
Сообщения: 260
роутинг включен.

необходимо обеспечить для вилан_11 отдельный от остальных дефолтный маршрут из 6509.


11 мар 2010, 14:41
Профиль WWW
Супермодератор

Зарегистрирован: 01 окт 2008, 12:24
Сообщения: 4434
Вот это совсем не нужно:

match ip next-hop acl_defGW

У вас 2 match, которые, если я правильно понял, никогда не выполняются.

Не понятно, правда, почему трафик дропится, но для начала я бы это убрал


11 мар 2010, 16:07
Профиль

Зарегистрирован: 18 ноя 2009, 20:20
Сообщения: 260
У меня на 6509 есть еще маршруты в другие сети, поэтому и два матча ставил - чтобы однозначно определить что меняем некст-хоп для пакета уходящего в интернет..


11 мар 2010, 16:11
Профиль WWW

Зарегистрирован: 18 ноя 2009, 20:20
Сообщения: 260
Всем спасибо!

Проблема решена, вот рабочий мап:
route-map defGW, permit, sequence 10
Match clauses:
ip address (access-lists): acl_netw
Set clauses:
ip default next-hop 10.200.200.200
Policy routing matches: 39 packets, 5037 bytes


Тему можно закрыть.


11 мар 2010, 17:23
Профиль WWW
Супермодератор

Зарегистрирован: 01 окт 2008, 12:24
Сообщения: 4434
Ок, закроем. Но на будущее: по-моему там всегда
match-all.

Чтобы указать 2 критерия надо сделать 2 абзаца:

route-map MAP 10
match {критерий1}
set {условие1}
route-map MAP 20
match {критерий2}
set {условие1}

и ещё часто бываtт полезно в конце указать (не обязательно)

route-map MAP 1000
set {условие по умолчанию}


11 мар 2010, 18:16
Профиль

Зарегистрирован: 18 ноя 2009, 20:20
Сообщения: 260
Fedia писал(а):
Ок, закроем. Но на будущее: по-моему там всегда
match-all.


Я так и задумывал - мне же нужно было чтобы некст-хоп новый устанавливался только для тех пакетов которые уже направились в сторону интернета, а остальные, идущие в другие подсети ЛАНа, мне трогать не нужно было.. т.е. нужно было одновременное выполнение обоих условий.

просто что-то работало не так, может аклы я неправильно прописал...

Fedia писал(а):
и ещё часто бываtт полезно в конце указать (не обязательно)

route-map MAP 1000
set {условие по умолчанию}


Спасибо, учту ;)


11 мар 2010, 21:06
Профиль WWW

Зарегистрирован: 18 ноя 2009, 20:20
Сообщения: 260
Пока тема не закрыта, я успеваю задать еще один вопрос :)

Итак, роут-мап у меня есть.
Повесил я его на int_vlan.
У С6509 есть несколько (4) Te-линка по которым он связан с другими ЛАН сегментами.

Необходимо применить данный роут-мап к пакетам приходящим от одного удаленного сегмента.
Маршрут в данный сегмент лежит через все 4 Те-интерфейса.

Вопрос:

Как отразится на производительности коммутатора установка роут-мапа на Те-интерфейсы?
И правильно ли использовать для этого роут-мап?


12 мар 2010, 07:21
Профиль WWW

Зарегистрирован: 20 окт 2009, 18:55
Сообщения: 962
насколько я помню, PBR в любом случае делается через CPU, со всеми вытекающими...


12 мар 2010, 10:16
Профиль

Зарегистрирован: 18 ноя 2009, 20:20
Сообщения: 260
Ilya писал(а):
насколько я помню, PBR в любом случае делается через CPU, со всеми вытекающими...

Читал на циске что через cef, или я ошибаюсь?


12 мар 2010, 10:25
Профиль WWW

Зарегистрирован: 02 июн 2009, 14:42
Сообщения: 231
PBR должна работать через CEF, аппаратная поддержка осуществляется, рекоммендации Cisco привожу ниже:

Release Notes for Cisco IOS Release 12.2(33)SXH and Later Releases - Features [Cisco Catalyst 6500 Series Switches]:
http://www.cisco.com/en/US/docs/switche ... tures.html

Policy-based routing (PBR) with hardware assist for route-map sequences that use the match ip address, set ip next-hop, and set ip default next-hop PBR keywords.

When configuring PBR, follow these guidelines and restrictions:

–Releases earlier than Release 12.2(33)SXH use the syntax from Release 12.1, which supports preempt as a keyword for the standby priority command. Release 12.2(33)SXH and later releases use the Release 12.2 syntax, which requires standby preempt and standby priority to be entered as separate commands:

–The PFC provides hardware support for PBR configured on a tunnel interface.

–The PFC does not provides hardware support for PBR configured with the set ip next-hop keywords if the next hop is a tunnel interface.

–If the MSFC address falls within the range of a PBR ACL, traffic addressed to the MSFC is policy routed in hardware instead of being forwarded to the MSFC. To prevent policy routing of traffic addressed to the MSFC, configure PBR ACLs to deny traffic addressed to the MSFC. (CSCse86399)

–Any options in Cisco IOS ACLs that provide filtering in a PBR route map that would cause flows to be sent to the MSFC3 to be switched in software are ignored. For example, logging is not supported in ACEs in Cisco IOS ACLs that provide filtering in PBR route maps.

–PBR traffic through switching module ports where PBR is configured is routed in software if the switching module resets. (CSCee92191)


12 мар 2010, 13:07
Профиль

Зарегистрирован: 20 окт 2009, 18:55
Сообщения: 962
каюсь, внес путаницу.


12 мар 2010, 21:34
Профиль

Зарегистрирован: 18 ноя 2009, 20:20
Сообщения: 260
Хорошо, с нагрузкой процессора разобрались.

Теперь перейдем ко второй части вопроса - насколько верно вешать такой роут-мап на аплинки в сторону ЛАНа с дизайнерской точки зрения? если нет, то что в данном случае лучше?


13 мар 2010, 00:10
Профиль WWW

Зарегистрирован: 02 июн 2009, 14:42
Сообщения: 231
На мой взгляд, PBR в данном случае самое логичное решение, других решений я пока не знаю. Если нужно маршрутизировать трафик по адресу источника, то PBR как раз то, что нужно. Основное ограничение PBR - плохая масштабируемость, по дизайну как раз это основной недостаток.


13 мар 2010, 16:51
Профиль

Зарегистрирован: 18 ноя 2009, 20:20
Сообщения: 260
На самом деле PBR в нашем случае временный (надеюсь) костыль - до времени организации полноценного EDGE...


13 мар 2010, 19:59
Профиль WWW
Показать сообщения за:  Поле сортировки  
Эта тема закрыта, вы не можете редактировать и оставлять сообщения в ней.   [ Сообщений: 16 ] 

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 6


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF.
Русская поддержка phpBB