Jump to content
Калькуляторы

ESR1008 cef Trouble Откуда взязлись некоторые записи?

Имеем:

абоненты---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

 

Вопрос: как оно туда попало, и как это убрать?

 

 

Share this post


Link to post
Share on other sites
Имеем:

абоненты---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 by Konstantin Klimchev

Share this post


Link to post
Share on other sites
Konstantin Klimchev, а если дать clear ip route * да понимаю что вычистим всю таблицу но чем черт не шутит

Share this post


Link to post
Share on other sites
Konstantin Klimchev, а если дать clear ip route * да понимаю что вычистим всю таблицу но чем черт не шутит

не шутит :(

тоже делал. да и нету их в обычной таблице.

Share this post


Link to post
Share on other sites
Konstantin Klimchev, а если дать clear ip route * да понимаю что вычистим всю таблицу но чем черт не шутит
не шутит :(

тоже делал. да и нету их в обычной таблице.

Была похожая беда в 7600 с SRA. Кроме ребута решения так и не нашлось :(

Кстати в августе для ESR вышел 12.2.33-SB7, в нём наконец починили accounting c гигавордсами.

Share this post


Link to post
Share on other sites
Konstantin Klimchev, а если дать clear ip route * да понимаю что вычистим всю таблицу но чем черт не шутит
не шутит :(

тоже делал. да и нету их в обычной таблице.

Была похожая беда в 7600 с SRA. Кроме ребута решения так и не нашлось :(

:(

и меня похоже это ждет. хорошо хоть грузится быстро...

 

Кстати в августе для ESR вышел 12.2.33-SB7, в нём наконец починили accounting c гигавордсами.

о. а это нужная информация. хотя пока не готов на 33 перелезать, до SB10 по крайней мере

 

Share this post


Link to post
Share on other sites

Нормально, баги примерно те же, что и в 31-SB11, зато есть новые фичи. :)

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

 

Кстати, наиболее стабильный IOS из 31 - SB11, в более новых багов добавили. :(

хорошо хоть грузится быстро...
Везёт. У меня грузится с нуля минут 10-15, так что redudancy очень кстати.

 

Share this post


Link to post
Share on other sites
Нормально, баги примерно те же, что и в 31-SB11, зато есть новые фичи. :)

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

Это есть...

 

Кстати, наиболее стабильный IOS из 31 - SB11, в более новых багов добавили. :(

Хм.... я то только пару недель назад с SB10 на SB16 переехал... повелся на LD

 

хорошо хоть грузится быстро...
Везёт. У меня грузится с нуля минут 10-15, так что redudancy очень кстати.

Edited by Konstantin Klimchev

Share this post


Link to post
Share on other sites
Нормально, баги примерно те же, что и в 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.... на интерфейсе?

 

Share this post


Link to post
Share on other sites
Кстати, наиболее стабильный IOS из 31 - SB11, в более новых багов добавили. :(
Хм.... я то только пару недель назад с SB10 на SB16 переехал... повелся на LD

Ну, это на моих задачах (IPoEoQinQ, NetFlow), у Вас может другой набор фич использоваться...

Кстати, sampled Netflow в 33SB7 работает неправильно, как и в SB11. Но хоть его можно выключить без перезагрузки. :)

Share this post


Link to post
Share on other sites
Ну, это на моих задачах (IPoEoQinQ, NetFlow), у Вас может другой набор фич использоваться...

IPoEoQinQ, PPPoEoQinQ, NetFlow, ISG. Штатный набор....

Share this post


Link to post
Share on other sites

В общем по итогу:

 

По прошествии 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" не доходит и проблема не проявляется.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this