Перейти к содержимому
Калькуляторы

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

 

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Имеем:

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

 

 

видать перегружать придется.....

Изменено пользователем Konstantin Klimchev

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

не шутит :(

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

:(

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

 

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Это есть...

 

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

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

 

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

Изменено пользователем Konstantin Klimchev

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А как вы без него живете?

а не знаю как.... выше по сети оно включено.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.