Проблемы со static routes на 7600 ...
Добрый день. Столкнулся с проблемкой на 7600 в следующей конфигурации: core#sh module Mod Ports Card Type Model Serial No. --- ----- -------------------------------------- ------------------ ----------- 1 2 Route Switch Processor 720 (Hot) RSP720-3CXL-GE xxxxxxxxxxx 2 2 Route Switch Processor 720 (Active) RSP720-3CXL-GE xxxxxxxxxxx 3 24 CEF720 24 port 1000mb SFP WS-X6724-SFP xxxxxxxxxxx Mod MAC addresses Hw Fw Sw Status --- ---------------------------------- ------ ------------ ------------ ------- 1 xxxxxxxxxxxxxx to xxxxxxxxxxxxxx 5.2 12.2(33r)SRB 12.2(33)SRB2 Ok 2 xxxxxxxxxxxxxx to xxxxxxxxxxxxxx 5.2 12.2(33r)SRB 12.2(33)SRB2 Ok 3 xxxxxxxxxxxxxx to xxxxxxxxxxxxxx 2.6 12.2(14r)S5 12.2(33)SRB2 Ok Mod Sub-Module Model Serial Hw Status ---- --------------------------- ------------------ ----------- ------- ------- 1 Policy Feature Card 3 7600-PFC3CXL xxxxxxxxxxx 1.0 Ok 1 C7600 MSFC4 Daughterboard 7600-MSFC4 xxxxxxxxxxx 1.1 Ok 2 Policy Feature Card 3 7600-PFC3CXL xxxxxxxxxxx 1.0 Ok 2 C7600 MSFC4 Daughterboard 7600-MSFC4 xxxxxxxxxxx 1.1 Ok 3 Centralized Forwarding Card WS-F6700-CFC xxxxxxxxxxx 4.0 Ok Mod Online Diag Status ---- ------------------- 1 Pass 2 Pass 3 Pass После принудительного переключения на резерв (при помощи "redundancy force-switchover") получил следующую картину: core#sh ip ro 192.168.89.1 % Subnet not in table core#sh run | inc ip route 192.168.0.0 ip route 192.168.0.0 255.255.0.0 Null0 250 т.е. в конфигурации маршрут есть, но в таблице маршрутизации его нет :( core#sh ip ro 10.44.44.44 % Subnet not in table core#sh run | inc ip route 10.0.0.0 ip route 10.0.0.0 255.0.0.0 Null0 250 После удаления и восстановления из конфигурации этого статического маршрута, он появляется в таблице маршрутизации : core#conf t Enter configuration commands, one per line. End with CNTL/Z. core(config)#no ip route 10.0.0.0 255.0.0.0 Null0 250 core(config)#ip route 10.0.0.0 255.0.0.0 Null0 250 core(config)#^Z core#sh ip ro 10.44.44.44 Routing entry for 10.0.0.0/8 Known via "static", distance 250, metric 0 (connected) Redistributing via eigrp 3261, bgp 3261 Advertised by eigrp 3261 route-map redistribute-from-static Routing Descriptor Blocks: * directly connected, via Null0 Route metric is 0, traffic share count is 1 Может быть кто-то сталкивался с подобным поведением? Что делать, что бы это больше не повторялось? PS. Есть ли кто-нибудь в этой рассылке, использующий 7600 RSP720 у себя в production ? =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Добрый день! On Fri, Jan 25, 2008 at 02:11:12PM +0200, Yury Yaroshevsky wrote:
Столкнулся с проблемкой на 7600 в следующей конфигурации:
...
После принудительного переключения на резерв (при помощи "redundancy force-switchover") получил следующую картину:
core#sh ip ro 192.168.89.1 % Subnet not in table core#sh run | inc ip route 192.168.0.0 ip route 192.168.0.0 255.255.0.0 Null0 250
т.е. в конфигурации маршрут есть, но в таблице маршрутизации его нет :(
...
Может быть кто-то сталкивался с подобным поведением? Что делать, что бы это больше не повторялось?
А что в это время было в FIB? Что пишет? Router#sh mls cef lookup XX.XX.XX.XX Поведение устойчиво повторяется? А как насчет обычного static: ip route A.A.A.A B.B.B.B C.C.C.C тоже самое?
PS. Есть ли кто-нибудь в этой рассылке, использующий 7600 RSP720 у себя в production ?
Да. под SRC -- Dmitry Kiselev =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Dmitry Kiselev пишет:
On Fri, Jan 25, 2008 at 02:11:12PM +0200, Yury Yaroshevsky wrote:
Столкнулся с проблемкой на 7600 в следующей конфигурации:
...
После принудительного переключения на резерв (при помощи "redundancy force-switchover") получил следующую картину:
core#sh ip ro 192.168.89.1 % Subnet not in table core#sh run | inc ip route 192.168.0.0 ip route 192.168.0.0 255.255.0.0 Null0 250
т.е. в конфигурации маршрут есть, но в таблице маршрутизации его нет :(
...
Может быть кто-то сталкивался с подобным поведением? Что делать, что бы это больше не повторялось?
А что в это время было в FIB? Что пишет?
Router#sh mls cef lookup XX.XX.XX.XX
core#sh mls cef lookup 192.168.0.0 Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency 249952 0.0.0.0/0 Vlxxxx , xxxxxxxxxxxx В сторону одного из Uplink.
Поведение устойчиво повторяется? А как насчет обычного static: ip route A.A.A.A B.B.B.B C.C.C.C тоже самое?
Дело в том, что проблема проявилась только для тех маршрутов, для которых distance metric был указан 250. Там где он не был указал - все нормально. Поведение сейчас на стенде проверяю.
PS. Есть ли кто-нибудь в этой рассылке, использующий 7600 RSP720 у себя в production ?
Да. под SRC
=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Добрый день! On Fri, Jan 25, 2008 at 03:33:36PM +0200, Yury Yaroshevsky wrote:
А что в это время было в FIB? Что пишет?
Router#sh mls cef lookup XX.XX.XX.XX
core#sh mls cef lookup 192.168.0.0
Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency 249952 0.0.0.0/0 Vlxxxx , xxxxxxxxxxxx
В сторону одного из Uplink.
Поведение устойчиво повторяется? А как насчет обычного static: ip route A.A.A.A B.B.B.B C.C.C.C тоже самое?
Дело в том, что проблема проявилась только для тех маршрутов, для которых distance metric был указан 250. Там где он не был указал - все нормально.
Поведение сейчас на стенде проверяю.
Можно не проверять. Если CEF сказал "в Vlxxxx", то туда оно и отфорвардится. А с проблемой однозначно нужно в TAC. -- Dmitry Kiselev =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Задам еще один вопрос. Стояла в лабе 7604 с одной платой CXL, я выдернул из работающего шасси резервный модель и перекинул его в лабу. При этом режим redundancy сконфигурирован как SSO. Но после загрузки подброшенной платы я получаю переход в RPR: Jan 26 11:37:03.638 EET: %ISSU-SP-3-INCOMPATIBLE_PEER_UID: Peer image (c7600rsp72043_sp-ADVIPSERVICESK9-M), version (12.2(33)SRB2) on peer uid (2) is incompatible Jan 26 11:37:22.246 EET: %PFREDUN-SP-4-INCOMPATIBLE: Defaulting to RPR mode (Runtime incompatible) Jan 26 11:37:27.841 EET: %FABRIC-SP-5-CLEAR_BLOCK: Clear block option is off for the fabric in slot 2. Jan 26 11:37:27.925 EET: %FABRIC-SP-5-FABRIC_MODULE_BACKUP: The Switch Fabric Module in slot 2 became standby Jan 26 11:37:28.561 EET: %DIAG-SP-6-RUN_MINIMUM: Module 2: Running Minimal Diagnostics... Jan 26 11:37:30.062 EET: %DIAG-SP-6-DIAG_OK: Module 2: Passed Online Diagnostics Jan 26 11:37:30.586 EET: %OIR-SP-6-INSCARD: Card inserted in slot 2, interfaces are now online Jan 26 11:39:53.249 EET: %PFREDUN-SP-6-ACTIVE: Standby initializing for RPR mode Jan 26 11:39:53.465 EET: %SYS-SP-3-LOGGER_FLUSHED: System was paused for 00:00:00 to ensure console debugging output. Jan 26 11:39:54.761 EET: %PFINIT-SP-5-CONFIG_SYNC: Sync'ing the startup configuration to the standby Router. Jan 26 11:40:01.953 EET: %RF-SP-5-RF_TERMINAL_STATE: Terminal state reached for (RPR) Какого лешего? IOS ведь загружены одинаковые? Redundant System Information : ------------------------------ Available system uptime = 7 weeks, 3 days, 15 hours, 38 minutes Switchovers system experienced = 2 Standby failures = 2 Last switchover reason = active unit removed Hardware Mode = Duplex Configured Redundancy Mode = sso Operating Redundancy Mode = rpr Maintenance Mode = Disabled Communications = Up Current Processor Information : ------------------------------- Active Location = slot 1 Current Software state = ACTIVE Uptime in current state = 7 weeks, 1 day, 20 hours, 13 minutes Image Version = Cisco IOS Software, c7600rsp72043_rp Software (c7600rsp72043_rp-ADVIPSERVICESK9-M), Version 12.2(33)SRB2, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2007 by Cisco Systems, Inc. Compiled Wed 10-Oct-07 08:10 by prod_rel_team BOOT = bootdisk:c7600rsp72043-advipservicesk9-mz.122-33.SRB2.bin,12; CONFIG_FILE = BOOTLDR = Configuration register = 0x2102 Peer Processor Information : ---------------------------- Standby Location = slot 2 Current Software state = STANDBY COLD Uptime in current state = 3 minutes Image Version = Cisco IOS Software, c7600rsp72043_rp Software (c7600rsp72043_rp-ADVIPSERVICESK9-M), Version 12.2(33)SRB2, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2007 by Cisco Systems, Inc. Compiled Wed 10-Oct-07 08:10 by prod_rel_team BOOT = bootdisk:c7600rsp72043-advipservicesk9-mz.122-33.SRB2.bin,12; CONFIG_FILE = BOOTLDR = Configuration register = 0x2102 Не сталкивались с таким поведением? =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Добрый день! On Sat, Jan 26, 2008 at 12:09:52PM +0200, Yury Yaroshevsky wrote:
Задам еще один вопрос.
Стояла в лабе 7604 с одной платой CXL, я выдернул из работающего шасси резервный модель и перекинул его в лабу. При этом режим redundancy сконфигурирован как SSO.
Но после загрузки подброшенной платы я получаю переход в RPR:
Jan 26 11:37:03.638 EET: %ISSU-SP-3-INCOMPATIBLE_PEER_UID: Peer image (c7600rsp72043_sp-ADVIPSERVICESK9-M), version (12.2(33)SRB2) on peer uid (2) is incompatible ... Jan 26 11:39:54.761 EET: %PFINIT-SP-5-CONFIG_SYNC: Sync'ing the startup configuration to the standby Router. ...
Какого лешего? IOS ведь загружены одинаковые?
Скорее всего slave's startup-config был отличен от master's running-config: одинаковые конфиги обязательное условие для SSO. После синхронизации и еще одной перезагрузки слейва, должен поднятся сразу в SSO. Если не поднимется, нужно в TAC, пускай индусы голову ломают :) -- Dmitry Kiselev =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Dmitry Kiselev пишет:
Добрый день!
On Sat, Jan 26, 2008 at 12:09:52PM +0200, Yury Yaroshevsky wrote:
Задам еще один вопрос.
Стояла в лабе 7604 с одной платой CXL, я выдернул из работающего шасси резервный модель и перекинул его в лабу. При этом режим redundancy сконфигурирован как SSO.
Но после загрузки подброшенной платы я получаю переход в RPR:
Jan 26 11:37:03.638 EET: %ISSU-SP-3-INCOMPATIBLE_PEER_UID: Peer image (c7600rsp72043_sp-ADVIPSERVICESK9-M), version (12.2(33)SRB2) on peer uid (2) is incompatible ... Jan 26 11:39:54.761 EET: %PFINIT-SP-5-CONFIG_SYNC: Sync'ing the startup configuration to the standby Router. ...
Какого лешего? IOS ведь загружены одинаковые?
Скорее всего slave's startup-config был отличен от master's running-config: одинаковые конфиги обязательное условие для SSO. После синхронизации и еще одной перезагрузки слейва, должен поднятся сразу в SSO. Если не поднимется, нужно в TAC, пускай индусы голову ломают :)
А как можно рестартовать standby при поможи команд, не вынимая плату? =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Yury Yaroshevsky пишет:
А как можно рестартовать standby при поможи команд, не вынимая плату?
После отправки вспомнил как это сделать. Но раз уж задал вопрос, то и отвечу на него сам: core#conf t Enter configuration commands, one per line. End with CNTL/Z. core(config)#redundancy core(config-red)#mode sso Changing to sso mode will reset the standby. Do you want to continue? [confirm] p60-core.dn(config-red)#^Z =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Добрый день! On Mon, Jan 28, 2008 at 11:15:48PM +0200, Yury Yaroshevsky wrote:
А как можно рестартовать standby при поможи команд, не вынимая плату?
После отправки вспомнил как это сделать. Но раз уж задал вопрос, то и отвечу на него сам:
core#conf t Enter configuration commands, one per line. End with CNTL/Z. core(config)#redundancy core(config-red)#mode sso Changing to sso mode will reset the standby. Do you want to continue? [confirm] p60-core.dn(config-red)#^Z
Страсти-то какие :) Router#hw-module module 2 reset -- Dmitry Kiselev =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Добрый день. Dmitry Kiselev пишет:
Страсти-то какие :)
Router#hw-module module 2 reset
Я подозревал что-либо подобное, но не хватило времени дочитать. Ну и нашел другой способ :))) Спасибо. Но теперь другая штука вылезла. После выполнения ISSU у меня standby переключился в RPR режим. Вероятно из-за этого : core#sh redundancy config-sync failures mcl Mismatched Command List ----------------------- router ospf xxxx ! <submode> "router" - no passive-interface Control Plane ! </submode> "router" Но заходя в конфигурацию ospf вижу : core.dn#conf t Enter configuration commands, one per line. End with CNTL/Z. core(config)#router ospf xxxx core(config-router)#no passive-interface ? Async Async interface Auto-Template Auto-Template interface CEM Circuit Emulation interface CTunnel CTunnel interface Container Container interface Dialer Dialer interface EsconPhy ESCON interface Filter Filter interface Filtergroup Filter Group interface GigabitEthernet GigabitEthernet IEEE 802.3z Group-Async Async Group interface LongReachEthernet Long-Reach Ethernet interface Loopback Loopback interface MFR Multilink Frame Relay bundle interface Multilink Multilink-group interface Null Null interface Port-channel Ethernet Channel of interfaces Portgroup Portgroup interface Pos-channel POS Channel of interfaces SBC Session Border Controller SYSCLOCK Telecom-Bus Clock Controller Tunnel Tunnel interface Vif PGM Multicast Host interface Virtual-PPP Virtual PPP interface Virtual-Template Virtual Template interface Virtual-TokenRing Virtual TokenRing Virtual-cem Circuit Emulation Virtual interface Vlan Catalyst Vlans default Suppress routing updates on all interfaces fcpa Fiber Channel multiservice Multiservice interface voaBypassIn VOA-Bypass-In interface voaBypassOut VOA-Bypass-Out interface voaFilterIn VOA-Filter-In interface voaFilterOut VOA-Filter-Out interface voaIn VOA-In interface voaOut VOA-Out interface Где здесаь 'Control Plane' ??? Но в тоже время и в running и в startup вижу : core#sh startup-config | inc Control no passive-interface Control Plane core# Ладно убрал/восстановил эту секцию ospf и записал после этого startup. После этого ни в startup ни в running нет 'no passive-interface Control Plane' После чего передернул standby - без результатно :( После загрузки тот же RPR. В логах вижу следующее: Jan 29 13:48:41.930 EET: %OIR-SP-3-PWRCYCLE: Card in module 2, is being power-cycled (Module reset) Jan 29 13:48:42.166 EET: %PFREDUN-SP-6-ACTIVE: Standby processor removed or reloaded, changing to Simplex mode Jan 29 13:49:42.767 EET: %ISSU-SP-3-PEER_IMAGE_INCOMPATIBLE: Peer image (c7600rsp72043_sp-ADVIPSERVICESK9-M), version (12.2(33)SRC) on peer uid (2) is incompatible Jan 29 13:49:42.767 EET: %ISSU-SP-3-PEER_IMAGE_INCOMPATIBLE: Peer image (c7600rsp72043_sp-ADVIPSERVICESK9-M), version (12.2(33)SRC) on peer uid (2) is incompatible Jan 29 13:50:02.186 EET: %PFREDUN-SP-4-INCOMPATIBLE: Defaulting to RPR mode (Runtime incompatible) Jan 29 13:50:06.686 EET: %FABRIC-SP-5-CLEAR_BLOCK: Clear block option is off for the fabric in slot 2. Jan 29 13:50:06.770 EET: %FABRIC-SP-5-FABRIC_MODULE_BACKUP: The Switch Fabric Module in slot 2 became standby Jan 29 13:50:07.398 EET: %DIAG-SP-6-RUN_MINIMUM: Module 2: Running Minimal Diagnostics... Jan 29 13:50:09.078 EET: %DIAG-SP-6-DIAG_OK: Module 2: Passed Online Diagnostics Jan 29 13:50:09.442 EET: %OIR-SP-6-INSCARD: Card inserted in slot 2, interfaces are now online Jan 29 13:52:33.187 EET: %PFREDUN-SP-6-ACTIVE: Standby initializing for RPR mode Jan 29 13:52:33.403 EET: %SYS-SP-3-LOGGER_FLUSHED: System was paused for 00:00:00 to ensure console debugging output. Jan 29 13:52:41.275 EET: %RF-SP-5-RF_TERMINAL_STATE: Terminal state reached for (RPR) Что можно посоветовать в этой ситуации еще сделать (не считая обращения в TAC). =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Dmitry Kiselev пишет:
Добрый день!
On Fri, Jan 25, 2008 at 03:33:36PM +0200, Yury Yaroshevsky wrote:
А что в это время было в FIB? Что пишет?
Router#sh mls cef lookup XX.XX.XX.XX core#sh mls cef lookup 192.168.0.0
Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency 249952 0.0.0.0/0 Vlxxxx , xxxxxxxxxxxx
В сторону одного из Uplink.
Поведение устойчиво повторяется? А как насчет обычного static: ip route A.A.A.A B.B.B.B C.C.C.C тоже самое? Дело в том, что проблема проявилась только для тех маршрутов, для которых distance metric был указан 250. Там где он не был указал - все нормально.
Поведение сейчас на стенде проверяю.
Можно не проверять. Если CEF сказал "в Vlxxxx", то туда оно и отфорвардится.
А с проблемой однозначно нужно в TAC.
Может быть кому-то будет интерестно: Cобрал простенький стенд, если конечно 7600 можно назвать в данной ситуации простеньким ;) и прописал маршруты: ip route 0.0.0.0 0.0.0.0 195.184.x.x ip route 192.168.1.0 255.255.255.0 Null0 250 ip route 192.168.2.0 255.255.255.0 Null0 220 ip route 192.168.3.0 255.255.255.0 Null0 200 ip route 192.168.4.0 255.255.255.0 Null0 ip route 192.168.5.0 255.255.255.0 195.184.x.x После выполнения "redundancy force-switchover" из состояния: [skip] Hardware Mode = Duplex Configured Redundancy Mode = sso Operating Redundancy Mode = sso Maintenance Mode = Disabled Communications = Up [skip] Получил повторение проблемы: router-new#sh ip ro Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, + - replicated route Gateway of last resort is 195.184.x.x to network 0.0.0.0 S* 0.0.0.0/0 [1/0] via 195.184.x.x S 192.168.5.0/24 [1/0] via 195.184.x.x 195.184.x.0/24 is variably subnetted, 2 subnets, 2 masks C 195.184.x.z/27 is directly connected, GigabitEthernet3/0/0 L 195.184.x.y/32 is directly connected, GigabitEthernet3/0/0 router-new# Т.е. все маршруты прописанные в Null пропали из таблицы маршрутизации. Причем как и те которые были с distance 250 так и без явного указания distance. :((( При этом в ситуации когда я столкнулся с этим впервые - у меня пропали те статики, которые были прописаны с distance 250, остальные остались (даже идущий в Null без указания distance). После того как был выполнен upgrade до SRC и была выполнена попытка повторить эксперимент - проблема перестала наблюдаеться. Роуты из таблицы не пропадают. Видимо пофиксили. PS. По поводу SRB2 - один раз при переключении пропали и маршруты прописанные на конкретный gateway, а в Null оставались на месте. Но это было при выполнении ISSU. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Fri, Jan 25, 2008 at 02:11:12PM +0200, Yury Yaroshevsky wrote:
Может быть кто-то сталкивался с подобным поведением? Что делать, что бы это больше не повторялось?
Попробовать обновить IOS, если не поможет - описать проблему в cisco-nsp или открыть case.
PS. Есть ли кто-нибудь в этой рассылке, использующий 7600 RSP720 у себя в production ?
Есть. Но у нас он "тупой mpls-switch", справляется нормально. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
participants (3)
-
Alexandre Snarskii -
Dmitry Kiselev -
Yury Yaroshevsky