Konstantin Klimchev Posted October 20, 2009 Posted October 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 Вопрос: как оно туда попало, и как это убрать? Вставить ник Quote
Konstantin Klimchev Posted October 21, 2009 Author Posted October 21, 2009 (edited) Имеем:абоненты---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 ... видать перегружать придется..... Edited October 21, 2009 by Konstantin Klimchev Вставить ник Quote
VitMain Posted October 21, 2009 Posted October 21, 2009 Konstantin Klimchev, а если дать clear ip route * да понимаю что вычистим всю таблицу но чем черт не шутит Вставить ник Quote
Konstantin Klimchev Posted October 21, 2009 Author Posted October 21, 2009 Konstantin Klimchev, а если дать clear ip route * да понимаю что вычистим всю таблицу но чем черт не шутит не шутит :( тоже делал. да и нету их в обычной таблице. Вставить ник Quote
Cr_net Posted October 21, 2009 Posted October 21, 2009 Konstantin Klimchev, а если дать clear ip route * да понимаю что вычистим всю таблицу но чем черт не шутитне шутит :(тоже делал. да и нету их в обычной таблице. Была похожая беда в 7600 с SRA. Кроме ребута решения так и не нашлось :(Кстати в августе для ESR вышел 12.2.33-SB7, в нём наконец починили accounting c гигавордсами. Вставить ник Quote
Konstantin Klimchev Posted October 21, 2009 Author Posted October 21, 2009 Konstantin Klimchev, а если дать clear ip route * да понимаю что вычистим всю таблицу но чем черт не шутитне шутит :(тоже делал. да и нету их в обычной таблице. Была похожая беда в 7600 с SRA. Кроме ребута решения так и не нашлось :( :( и меня похоже это ждет. хорошо хоть грузится быстро... Кстати в августе для ESR вышел 12.2.33-SB7, в нём наконец починили accounting c гигавордсами. о. а это нужная информация. хотя пока не готов на 33 перелезать, до SB10 по крайней мере Вставить ник Quote
UglyAdmin Posted October 23, 2009 Posted October 23, 2009 Нормально, баги примерно те же, что и в 31-SB11, зато есть новые фичи. :) Настоятельно рекомендую иметь вторые мозги в redudancy, перезагрузка железки становится практически безболезненной. Кстати, наиболее стабильный IOS из 31 - SB11, в более новых багов добавили. :( хорошо хоть грузится быстро...Везёт. У меня грузится с нуля минут 10-15, так что redudancy очень кстати. Вставить ник Quote
Konstantin Klimchev Posted October 23, 2009 Author Posted October 23, 2009 (edited) Нормально, баги примерно те же, что и в 31-SB11, зато есть новые фичи. :)Настоятельно рекомендую иметь вторые мозги в redudancy, перезагрузка железки становится практически безболезненной. Это есть... Кстати, наиболее стабильный IOS из 31 - SB11, в более новых багов добавили. :( Хм.... я то только пару недель назад с SB10 на SB16 переехал... повелся на LD хорошо хоть грузится быстро...Везёт. У меня грузится с нуля минут 10-15, так что redudancy очень кстати. Edited October 23, 2009 by Konstantin Klimchev Вставить ник Quote
Konstantin Klimchev Posted October 26, 2009 Author Posted October 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.... на интерфейсе? Вставить ник Quote
Konstantin Klimchev Posted October 26, 2009 Author Posted October 26, 2009 А как вы без него живете? а не знаю как.... выше по сети оно включено. Вставить ник Quote
UglyAdmin Posted October 27, 2009 Posted October 27, 2009 Кстати, наиболее стабильный IOS из 31 - SB11, в более новых багов добавили. :(Хм.... я то только пару недель назад с SB10 на SB16 переехал... повелся на LD Ну, это на моих задачах (IPoEoQinQ, NetFlow), у Вас может другой набор фич использоваться...Кстати, sampled Netflow в 33SB7 работает неправильно, как и в SB11. Но хоть его можно выключить без перезагрузки. :) Вставить ник Quote
Konstantin Klimchev Posted October 27, 2009 Author Posted October 27, 2009 Ну, это на моих задачах (IPoEoQinQ, NetFlow), у Вас может другой набор фич использоваться... IPoEoQinQ, PPPoEoQinQ, NetFlow, ISG. Штатный набор.... Вставить ник Quote
Konstantin Klimchev Posted October 29, 2009 Author Posted October 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" не доходит и проблема не проявляется. Вставить ник Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.