Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
New generation switching modules may be stuck in booting state when applying VASI NAT configuration. Chassis type: ISR4451-X/K9 Slot Type State Insert time (ago) --------- ------------------- --------------------- ----------------- ... 1/0 SM-X-16G4M2X booting 00:01:09 The module will be stuck on booting and you will logs indicating a process crashing: *Jun 29 15:28:48.635: %SPA_OIR-6-OFFLINECARD: SPA (SM-X-16G4M2X) offline in subslot 1/0 *Jun 29 15:29:25.207: %PMAN-3-PROCHOLDDOWN: C1/0: fman_cc: The process fman_cc has been helddown (rc 139) *Jun 29 15:29:30.578: %IOMD-3-MODULE_MESSAGE: C1/0: iomd: SM-X-16G4M2X[1/0] NGIO control packet loss detected: module reloading *Jun 29 15:29:35.600: %SPA_OIR-6-OFFLINECARD: SPA (SM-X-16G4M2X) offline in subslot 1/0 There will be core files from the fman process (or system reports with that insiede) from the time of the reboot. These files may be analyzed by TAC if you need further confirmation
This has been seen so far with: * C-SM-16P4M2X on c8300 * SM-X-16G4M2X on ISR4k
1. Remove VASI interfaces, force reload the module and add VASI config agian. 2. Remove VASI configuration 3. Enable maintenance mode(works with even if is VASI enabled). If you want to avoid VASI you can use a tunnel between 2 loopback interfaces on the same router, one loopback is the source, the other- the tunnel destination. There should be two tunnel interfaces with their config mirrored. For example, the first is in vrf 1, the second in the other vrf(2) or global vrf and it becomes something like vasileft/vasiright
device : C8300-1N1S-4T2X module : C-SM-16P4M2X IOS : 17.04.01b Firmware Version : 17.3(1r) Issue reproduced in TAC lab. The module C-SM-16P4M2X going down and stuck in booting state if we have VASI NAT configuration though we don't have NAT config on module interfaces. Multiple reload of the module or router, and OIR of the module does not fix the issue. There are 2 situations: 1. VASI NAT configuration is there and module is running fine. Once we reload the module or router, it doesn't comes up and stuck in booting state. 2. Sometimes, when we configure VASI interfaces, the module goes down and remains in booting state as below logs show: ROUTER(config)#int vasileft 1 ROUTER(config-if)#ip address 1.1.1.1 255.255.255.0 ROUTER(config-if)#no shu ROUTER(config-if)#int vasiri1 *Mar 13 10:10:17.818 ZULU: %LINEPROTO-5-UPDOWN: Line protocol on Interface vasiright1, changed state to up *Mar 13 10:10:17.818 ZULU: %LINK-3-UPDOWN: Interface vasiright1, changed state to up *Mar 13 10:10:17.818 ZULU: %LINEPROTO-5-UPDOWN: Line protocol on Interface vasileft1, changed state to up *Mar 13 10:10:17.820 ZULU: %LINK-3-UPDOWN: Interface vasileft1, changed state to up *Mar 13 10:10:20.518 ZULU: %PMAN-3-PROCHOLDDOWN: R0/0: root: The process fman_cc has been helddown (rc 139) *Mar 13 10:10:25.906 ZULU: %IOMD-3-MODULE_MESSAGE: R0/0: iomd: C-SM-16P4M2X[1/0] NGIO control packet loss detected: module reloading *Mar 13 10:10:36.935 ZULU: %SPA_OIR-6-OFFLINECARD: SPA (C-SM-16P4M2X) offline in subslot 1/0 *Mar 13 10:11:08.237 ZULU: %PMAN-3-PROCHOLDDOWN: R0/0: root: The process fman_cc has been helddown (rc 139) PSIRT Evaluation: The Cisco PSIRT has evaluated this issue and determined it does not meet the criteria for PSIRT ownership or involvement. This issue will be addressed via normal resolution channels. If you believe that there is new information that would cause a change in the severity of this issue, please contact psirt@cisco.com for another evaluation. Additional information on Cisco's security vulnerability policy can be found at the following URL: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html