Konstantin Klimchev Опубликовано 20 октября, 2009 · Жалоба Имеем: абоненты---ESR10008---ASA5550---ASR1002---инет на ESR поднят BGP (as65500) который отдает сети на ASR1002(asXYZ). ASR1002 отдает на ESR10008 только default. на ESR: 10000ESR#sh ver | i Version Cisco IOS Software, 10000 Software (C10K3-P11-M), Version 12.2(31)SB16, RELEASE SOFTWARE (fc2) ROM: System Bootstrap, Version 12.2(20061016:191909) [fyang-rom-1_3 101], DEVELOPMENT SOFTWARE 10000ESR#sh ip cef | e ^127.|^10.|^172.|^192.168.|^xx.yy.|^224.|^255. Prefix Next Hop Interface 0.0.0.0/0 xx.yy.224.105 GigabitEthernet5/1/0.3000 0.0.0.0/32 receive 194.149.67.130/32 xx.yy.224.105 GigabitEthernet5/1/0.3000 195.239.112.194/32 xx.yy.224.105 GigabitEthernet5/1/0.3000 212.14.176.210/32 xx.yy.224.105 GigabitEthernet5/1/0.3000 10000ESR#sh ip route 194.149.67.130 % Network not in table 10000ESR#sh ip route 195.239.112.194 % Network not in table 10000ESR#sh ip route 212.14.176.210 % Network not in table как следствие: не форвардит ESR пакеты на эти ip, хотя с самого ESR пакетики туда бегают. root@phantom:~# traceroute-nanog -n -s xx.yy.253.20 194.149.67.130 traceroute to 194.149.67.130 (194.149.67.130), 30 hops max, 40 byte packets 1 xx.yy.253.30 2.076 ms 0.203 ms 0.227 ms 2 xx.yy.253.30 0.256 ms !X * 0.203 ms !X xx.yy.253.20 - мой ip (проблемы для любых, кто идет через ESR) xx.yy.253.30 - ip sub'а ESR Вопрос: как оно туда попало, и как это убрать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Konstantin Klimchev Опубликовано 21 октября, 2009 (изменено) · Жалоба Имеем:абоненты---ESR10008---ASA5550---ASR1002---инет на ESR поднят BGP (as65500) который отдает сети на ASR1002(asXYZ). ASR1002 отдает на ESR10008 только default. на ESR: 10000ESR#sh ver | i Version Cisco IOS Software, 10000 Software (C10K3-P11-M), Version 12.2(31)SB16, RELEASE SOFTWARE (fc2) ROM: System Bootstrap, Version 12.2(20061016:191909) [fyang-rom-1_3 101], DEVELOPMENT SOFTWARE 10000ESR#sh ip cef | e ^127.|^10.|^172.|^192.168.|^xx.yy.|^224.|^255. Prefix Next Hop Interface 0.0.0.0/0 xx.yy.224.105 GigabitEthernet5/1/0.3000 0.0.0.0/32 receive 194.149.67.130/32 xx.yy.224.105 GigabitEthernet5/1/0.3000 195.239.112.194/32 xx.yy.224.105 GigabitEthernet5/1/0.3000 212.14.176.210/32 xx.yy.224.105 GigabitEthernet5/1/0.3000 10000ESR#sh ip route 194.149.67.130 % Network not in table 10000ESR#sh ip route 195.239.112.194 % Network not in table 10000ESR#sh ip route 212.14.176.210 % Network not in table как следствие: не форвардит ESR пакеты на эти ip, хотя с самого ESR пакетики туда бегают. root@phantom:~# traceroute-nanog -n -s xx.yy.253.20 194.149.67.130 traceroute to 194.149.67.130 (194.149.67.130), 30 hops max, 40 byte packets 1 xx.yy.253.30 2.076 ms 0.203 ms 0.227 ms 2 xx.yy.253.30 0.256 ms !X * 0.203 ms !X xx.yy.253.20 - мой ip (проблемы для любых, кто идет через ESR) xx.yy.253.30 - ip sub'а ESR Вопрос: как оно туда попало, и как это убрать? Физическое гашение интерфейса не помогает :( остается: 10000ESR#sh ip cef | e ^127.|^10.|^172.|^192.168.|^xx.yy.|^224.|^255. Prefix Next Hop Interface 0.0.0.0/0 no route 0.0.0.0/32 receive 194.149.67.130/32 no route 195.239.112.194/32 no route 212.14.176.210/32 no route Так же не помогают различные варианты: clear ip cef... clear cef ... видать перегружать придется..... Изменено 21 октября, 2009 пользователем Konstantin Klimchev Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VitMain Опубликовано 21 октября, 2009 · Жалоба Konstantin Klimchev, а если дать clear ip route * да понимаю что вычистим всю таблицу но чем черт не шутит Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Konstantin Klimchev Опубликовано 21 октября, 2009 · Жалоба Konstantin Klimchev, а если дать clear ip route * да понимаю что вычистим всю таблицу но чем черт не шутит не шутит :( тоже делал. да и нету их в обычной таблице. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cr_net Опубликовано 21 октября, 2009 · Жалоба Konstantin Klimchev, а если дать clear ip route * да понимаю что вычистим всю таблицу но чем черт не шутитне шутит :(тоже делал. да и нету их в обычной таблице. Была похожая беда в 7600 с SRA. Кроме ребута решения так и не нашлось :(Кстати в августе для ESR вышел 12.2.33-SB7, в нём наконец починили accounting c гигавордсами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Konstantin Klimchev Опубликовано 21 октября, 2009 · Жалоба Konstantin Klimchev, а если дать clear ip route * да понимаю что вычистим всю таблицу но чем черт не шутитне шутит :(тоже делал. да и нету их в обычной таблице. Была похожая беда в 7600 с SRA. Кроме ребута решения так и не нашлось :( :( и меня похоже это ждет. хорошо хоть грузится быстро... Кстати в августе для ESR вышел 12.2.33-SB7, в нём наконец починили accounting c гигавордсами. о. а это нужная информация. хотя пока не готов на 33 перелезать, до SB10 по крайней мере Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 23 октября, 2009 · Жалоба Нормально, баги примерно те же, что и в 31-SB11, зато есть новые фичи. :) Настоятельно рекомендую иметь вторые мозги в redudancy, перезагрузка железки становится практически безболезненной. Кстати, наиболее стабильный IOS из 31 - SB11, в более новых багов добавили. :( хорошо хоть грузится быстро...Везёт. У меня грузится с нуля минут 10-15, так что redudancy очень кстати. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Konstantin Klimchev Опубликовано 23 октября, 2009 (изменено) · Жалоба Нормально, баги примерно те же, что и в 31-SB11, зато есть новые фичи. :)Настоятельно рекомендую иметь вторые мозги в redudancy, перезагрузка железки становится практически безболезненной. Это есть... Кстати, наиболее стабильный IOS из 31 - SB11, в более новых багов добавили. :( Хм.... я то только пару недель назад с SB10 на SB16 переехал... повелся на LD хорошо хоть грузится быстро...Везёт. У меня грузится с нуля минут 10-15, так что redudancy очень кстати. Изменено 23 октября, 2009 пользователем Konstantin Klimchev Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Konstantin Klimchev Опубликовано 26 октября, 2009 · Жалоба Нормально, баги примерно те же, что и в 31-SB11, зато есть новые фичи. :)Настоятельно рекомендую иметь вторые мозги в redudancy, перезагрузка железки становится практически безболезненной. Это есть... Кстати, наиболее стабильный IOS из 31 - SB11, в более новых багов добавили. :( Хм.... я то только пару недель назад с SB10 на SB16 переехал... повелся на LD хорошо хоть грузится быстро...Везёт. У меня грузится с нуля минут 10-15, так что redudancy очень кстати. Фуф.... Вроде понятно откуда уши торчат. Есть несколько абонентов, которые подключены к нескольким провайдерам. Тип подключения у них IPoE с ip subscriber routed Как только от них приходит левенький пакетик с source-ip от другого подключения (их ip у другого оператора) так и происходит описанное мною. Диагностируется через #show pxf cpu vcci (в дополнение к описанному мною выше). Лечится через удаление и пересоздание на sub'е: ip subscriber routed Если переопределять явно next-hop то даже при наличии этих левых в cef'е - форвардится без ошибок. ЗЫ. строгий ip verify.... на интерфейсе? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bambuk Опубликовано 26 октября, 2009 · Жалоба А как вы без него живете? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Konstantin Klimchev Опубликовано 26 октября, 2009 · Жалоба А как вы без него живете? а не знаю как.... выше по сети оно включено. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 27 октября, 2009 · Жалоба Кстати, наиболее стабильный IOS из 31 - SB11, в более новых багов добавили. :(Хм.... я то только пару недель назад с SB10 на SB16 переехал... повелся на LD Ну, это на моих задачах (IPoEoQinQ, NetFlow), у Вас может другой набор фич использоваться...Кстати, sampled Netflow в 33SB7 работает неправильно, как и в SB11. Но хоть его можно выключить без перезагрузки. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Konstantin Klimchev Опубликовано 27 октября, 2009 · Жалоба Ну, это на моих задачах (IPoEoQinQ, NetFlow), у Вас может другой набор фич использоваться... IPoEoQinQ, PPPoEoQinQ, NetFlow, ISG. Штатный набор.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Konstantin Klimchev Опубликовано 29 октября, 2009 · Жалоба В общем по итогу: По прошествии 2-х суток описанные проблемы не повторились (после прописывания на интерфейсы ip verify unicast source reachable-via rx allow-default allow-self-ping) Могу предположить что: по пришествии пакета на интерфейс с неправильным source-ip поднимается ISGшный unauth сервис (в логах попытки неудачной авторизации есть) и неправильный ip каким-то образом попадает в cef-таблицу. После этого начинаются проблемы с форвардингом пакетов на этот неправильный ip. после прописывания на интерфейсе "ip verify unicast source reachable-via rx allow-default allow-self-ping" дело до ISGшного "ip subscriber routed -> initiator unclassified ip-address" не доходит и проблема не проявляется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...