Cat4900M unnumbered proxy-arp

[tartila]

Господа, еще один глупый вопрос.

 

Почему то как то через зад работает proxy-arp в Cat4900M (Cat4900M cat4500e-entservicesk9-mz.122-54.SG.bin).

 

===

!

interface Loopback 0

ip address 2.2.2.2 255.255.255.0 secondary

ip address 1.1.1.1 255.255.255.0

no ip rediects

!

inteface vlan 2

ip unnumbered Loopback0 poll

!

===

 

Catalyst запустил, клиенты насосались в Vlan2. Создаю еще Vlan.

 

===

!

inteface vlan 3

ip unnumbered Loopback0 poll

!

===

 

Перебрасываю живущих в Vlan2 в Vlan3 на свитчах и начинается сюрприз.

Те, кто остался в Vlan2 - работают нормально, а вот в Vlan3 работают через Опу.

Во-первых они не пингают Cisco по ICMP, хотя ARP приходит верный. Во-вторых они не пингают соседей по ICMP (из одного network в vlan2), лишь выборочно, в третьих они видят лишь огрызками Inet (то есть то, что дальше Cat), например 2 ip от ya.ru пингаются, 2 - нет. ;))) (я не больной и не под алкоголем :) traceroute в это время не показывает Cat, т.к. он не пингается )

Теперь, если я даю, например ip route 2.2.2.4 255.255.255.255 vlan3 , то магическим образом все начинает работать, но блин!, зачем тогда poll!!!

sh ip arp vlan 3 показывает, что абоники именно в этом vlan. arp -an на абонской машине в vlan3 показывает mac cisco.

Перегружать абоников пробовали, перегружать Cisco нет, ибо это бред - перегружать роутер после добавления Vlan. ;)))

Я так понимаю, что продолжается извечная ерня с arp polling и arp proxy и типо не могут быть более одного интерфейса с polling+proxy. ;)

 

p.s. Я так понимаю, что sh ip arp vlan 3 врет тут, но как это победить?

Edited August 6, 2011 by tartila

[tartila]

Тему up.

 

p.s. Никто так не юзает, что ли? :)

[darkagent]

arp proxy есть зло. при таком раскладе теряется смысл сегментации на вланы - можно тупо всех на один интерфейс сажать.

[tartila]

arp proxy есть зло. при таком раскладе теряется смысл сегментации на вланы - можно тупо всех на один интерфейс сажать.

 

Ну не скажите ;) Все же смысл есть, трафик рулится через Cisco в любой ситуации, а не бегает по L2 неуправляемым. Вообщем, холиварить не буду. Я уже понял, что похоже polling+proxyarp для больших сетей работает плохо, поэтому буду делать набивку через SNMP роут таблицы.

 

Кстати, может быть кто нибудь подкинет пару примеров для создания/удаления маршрутов на Cisco?

 

Интересует аналогия ip route x.x.x.x x.x.x.x vlan xxx

[ingress]

clear arp-cache надо делать когда флапаете вланы.

[tartila]

clear arp-cache надо делать когда флапаете вланы.

 

;) Это не серьезно. Что же, теперь чистить кэш и сбрасывать пользователей в VLAN, если один переход из VLAN в VLAN? (IP выдался другому человеку в другом VLAN)

[ingress]

когда включен poll трекается интерфейс, и по ответу смотрится куда строить adjacency, т.е. пока не сделать clear arp-cache или пустить gratuitos arp от машины то adjacency будет в старый интерфейс построена, глюки(как вы описали) которые при этом появляются довольно широкообразные: от полного отсутствия связности до свичинга процессором.

[tartila]

когда включен poll трекается интерфейс, и по ответу смотрится куда строить adjacency, т.е. пока не сделать clear arp-cache или пустить gratuitos arp от машины то adjacency будет в старый интерфейс построена, глюки(как вы описали) которые при этом появляются довольно широкообразные: от полного отсутствия связности до свичинга процессором.

 

Я понял Вас, спасибо большое за разъяснение, в чем именно проблема. Но меня не устраивает дергать живые Vlan, откуда мог в данный момент перескочить IP в другой Vlan. Это приведет к кратковременным разрывам связи. Я решил перестраивать таблицу роутинга в зависимости от положения IP. То есть реагировать на изменения так no ip route 1.1.1.1 255.255.255.255 и ip route 1.1.1.1 255.255.255.255 vlan Новый_VLAN.

 

p.s. Я приблизительно так себе и представлял, в чем именно проблема. Но все равно огромное спасибо за разъяснения.

[h1vs2]

arp proxy есть зло. при таком раскладе теряется смысл сегментации на вланы - можно тупо всех на один интерфейс сажать.

 

Кстати, может быть кто нибудь подкинет пару примеров для создания/удаления маршрутов на Cisco?

 

Интересует аналогия ip route x.x.x.x x.x.x.x vlan xxx

 

Столкнулись с отсутствием поллинга на 6509. Для себя решил костылем : биллинг генерирует файл вида : "ip route [ip] 255.255.255.255 vlan[X]", сравнивает диффом со старым файлом, добавлять "no" перед не актуальным роутами, и добавляет актуальные. Потом дается команда циске слить конфиг по тфтп, и заменяется старый файл новым.

Никакой синхронизации нет, все вот так. Пока проблем не возникало, но задумываемся о более правильном решении.

Edited August 8, 2011 by h1vs2

[tartila]

arp proxy есть зло. при таком раскладе теряется смысл сегментации на вланы - можно тупо всех на один интерфейс сажать.

 

Кстати, может быть кто нибудь подкинет пару примеров для создания/удаления маршрутов на Cisco?

 

Интересует аналогия ip route x.x.x.x x.x.x.x vlan xxx

 

Столкнулись с отсутствием поллинга на 6509. Для себя решил костылем : биллинг генерирует файл вида : "ip route [ip] 255.255.255.255 vlan[X]", сравнивает диффом со старым файлом, добавлять "no" перед не актуальным роутами, и добавляет актуальные. Потом дается команда циске слить конфиг по тфтп, и заменяется старый файл новым.

Никакой синхронизации нет, все вот так. Пока проблем не возникало, но задумываемся о более правильном решении.

 

Я думаю, Вы не много потеряли из-за отсутствия poll. Чувствуется, что в IOS, как в таковом, индусы просто забили на эту фичу и все работает через зад. Я, если честно, теперь жалею, может быть лучше было бы купить сервак процов на 8, с 8 Гб оперативы и картой 10GBE - получилось бы дешевле и более конфигурабельней. Но уже дело сделано, буду выпутываться из багов. По теме могу сказать Вам, что я уже реализовал алгоритм, суть его в телнетинге на Cisco аля

> login

> enable

# conf t

# (config) no ip route x.x.x.x 255.255.255.255

# (config) ip route x.x.x.x 255.255.255.255 vlan yyy name zzz

 

Работает бронебойно. Почитал MIB от Cisco и сделал для себя вывод, что эта гадина не RW для OID, касающихся FORWARD и для составления ACL. Сцуковые индусы! ;)

[darkagent]

если вы решаете первоочередные задачи ядра доступа через костыли - значит дизайн сети надо срочно переделывать, и обзавестись хотя бы на непродолжительное время полноценным проектировщиком, с уровнем знаний не ниже ccdp/ccnp.

 

Объясняю вашу проблему на пальцах: в какой то момент вы начинаете замечать что c4900M начинает медлено но верно захлебываться. вы заглядывается в sh proc cpu sort и видите как vty совместно с ip input начисто пожирают все процессорное время - и тут хочешь не хочешь, а костыли прийдется отправить в утиль.

так что пока не поздно, пересмотрите подход к вашей сети. все эти pbr, arp proxy+poll - это скорее в порядке исключений, для решения индивидуальных разовых задач, а не для масс.

иначе когда поднаберете абонентскую массу, и нагрузка в сети подрастет, вам уже будет значительно сложней исправлять все то что вы сейчас нагородили.

[martini]

а почему vty будет жрать проц ? у него же не 500 абонентов каждую секунду прыгают с влана на влан, раз прописал и пусть висят роуты пока абонент оплачивает.. да и правильно построенный pbr отрабатывается хардварно

[darkagent]

у него же не 500 абонентов каждую секунду прыгают с влана на влан

вы гарантируете что такого здеца не случится? всякое видал, от такого никто не застрахован, особенно когда масштабы большие.

[martini]

это должен гарантировать тот кто строил сеть , при использовании такого костыля нужно понимать от чего может быть затык и не допускать появления оного.

Edited August 9, 2011 by martini

[tartila]

если вы решаете первоочередные задачи ядра доступа через костыли - значит дизайн сети надо срочно переделывать, и обзавестись хотя бы на непродолжительное время полноценным проектировщиком, с уровнем знаний не ниже ccdp/ccnp.

 

Объясняю вашу проблему на пальцах: в какой то момент вы начинаете замечать что c4900M начинает медлено но верно захлебываться. вы заглядывается в sh proc cpu sort и видите как vty совместно с ip input начисто пожирают все процессорное время - и тут хочешь не хочешь, а костыли прийдется отправить в утиль.

так что пока не поздно, пересмотрите подход к вашей сети. все эти pbr, arp proxy+poll - это скорее в порядке исключений, для решения индивидуальных разовых задач, а не для масс.

иначе когда поднаберете абонентскую массу, и нагрузка в сети подрастет, вам уже будет значительно сложней исправлять все то что вы сейчас нагородили.

 

Да нет, martini, конечно прав. Я же не перезаливаю конфиг или тому подобные вещи. Приходит оплата и отправляется по telnet команда на добавление роута. Тут нюанс, что команда отправляется еще только и по start, но не по stop. И все это в очереди, не параллельно. То есть все команды выгребаются из очереди. Не вижу причин не перегрузки ядра, даже если будет 1000 абонентов на включение.