Автор |
Сообщение |
GByte
Зарегистрирован: 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 |
|
|
$0s
Зарегистрирован: 29 ноя 2009, 23:07 Сообщения: 234
|
А железка маршрутизировать не умеет? Вроде простым маршрутом должно решаться
|
11 мар 2010, 14:38 |
|
|
GByte
Зарегистрирован: 18 ноя 2009, 20:20 Сообщения: 260
|
роутинг включен.
необходимо обеспечить для вилан_11 отдельный от остальных дефолтный маршрут из 6509.
|
11 мар 2010, 14:41 |
|
|
Fedia
Супермодератор
Зарегистрирован: 01 окт 2008, 12:24 Сообщения: 4434
|
Вот это совсем не нужно:
match ip next-hop acl_defGW
У вас 2 match, которые, если я правильно понял, никогда не выполняются.
Не понятно, правда, почему трафик дропится, но для начала я бы это убрал
|
11 мар 2010, 16:07 |
|
|
GByte
Зарегистрирован: 18 ноя 2009, 20:20 Сообщения: 260
|
У меня на 6509 есть еще маршруты в другие сети, поэтому и два матча ставил - чтобы однозначно определить что меняем некст-хоп для пакета уходящего в интернет..
|
11 мар 2010, 16:11 |
|
|
GByte
Зарегистрирован: 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 |
|
|
Fedia
Супермодератор
Зарегистрирован: 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 |
|
|
GByte
Зарегистрирован: 18 ноя 2009, 20:20 Сообщения: 260
|
Fedia писал(а): Ок, закроем. Но на будущее: по-моему там всегда match-all.
Я так и задумывал - мне же нужно было чтобы некст-хоп новый устанавливался только для тех пакетов которые уже направились в сторону интернета, а остальные, идущие в другие подсети ЛАНа, мне трогать не нужно было.. т.е. нужно было одновременное выполнение обоих условий. просто что-то работало не так, может аклы я неправильно прописал... Fedia писал(а): и ещё часто бываtт полезно в конце указать (не обязательно)
route-map MAP 1000 set {условие по умолчанию} Спасибо, учту
|
11 мар 2010, 21:06 |
|
|
GByte
Зарегистрирован: 18 ноя 2009, 20:20 Сообщения: 260
|
Пока тема не закрыта, я успеваю задать еще один вопрос Итак, роут-мап у меня есть. Повесил я его на int_vlan. У С6509 есть несколько (4) Te-линка по которым он связан с другими ЛАН сегментами. Необходимо применить данный роут-мап к пакетам приходящим от одного удаленного сегмента. Маршрут в данный сегмент лежит через все 4 Те-интерфейса. Вопрос: Как отразится на производительности коммутатора установка роут-мапа на Те-интерфейсы? И правильно ли использовать для этого роут-мап?
|
12 мар 2010, 07:21 |
|
|
Ilya
Зарегистрирован: 20 окт 2009, 18:55 Сообщения: 962
|
насколько я помню, PBR в любом случае делается через CPU, со всеми вытекающими...
|
12 мар 2010, 10:16 |
|
|
GByte
Зарегистрирован: 18 ноя 2009, 20:20 Сообщения: 260
|
Ilya писал(а): насколько я помню, PBR в любом случае делается через CPU, со всеми вытекающими... Читал на циске что через cef, или я ошибаюсь?
|
12 мар 2010, 10:25 |
|
|
siv
Зарегистрирован: 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.htmlPolicy-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 |
|
|
Ilya
Зарегистрирован: 20 окт 2009, 18:55 Сообщения: 962
|
каюсь, внес путаницу.
|
12 мар 2010, 21:34 |
|
|
GByte
Зарегистрирован: 18 ноя 2009, 20:20 Сообщения: 260
|
Хорошо, с нагрузкой процессора разобрались.
Теперь перейдем ко второй части вопроса - насколько верно вешать такой роут-мап на аплинки в сторону ЛАНа с дизайнерской точки зрения? если нет, то что в данном случае лучше?
|
13 мар 2010, 00:10 |
|
|
siv
Зарегистрирован: 02 июн 2009, 14:42 Сообщения: 231
|
На мой взгляд, PBR в данном случае самое логичное решение, других решений я пока не знаю. Если нужно маршрутизировать трафик по адресу источника, то PBR как раз то, что нужно. Основное ограничение PBR - плохая масштабируемость, по дизайну как раз это основной недостаток.
|
13 мар 2010, 16:51 |
|
|
GByte
Зарегистрирован: 18 ноя 2009, 20:20 Сообщения: 260
|
На самом деле PBR в нашем случае временный (надеюсь) костыль - до времени организации полноценного EDGE...
|
13 мар 2010, 19:59 |
|
|