Switching

Expand all | Collapse all

On switch EX2300 there is failure of the virtual chassis?

Jump to Best Answer
  • 1.  On switch EX2300 there is failure of the virtual chassis?

    Posted 01-08-2020 13:18
    EX2300-VC mib2d[4488]: SNMP_TRAP_LINK_DOWN: ifIndex 650, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/29
    Jan  6 08:13:25  EX2300-VC mib2d[4488]: SNMP_TRAP_LINK_UP: ifIndex 650, ifAdminStatus up(1), ifOperStatus up(1), ifName ge-1/0/29
    Jan  6 08:13:35  EX2300-VC kernel: tcp_timer_keep: Dropping socket connection due to keepalive timer expiration, idle/intvl/cnt: 300/100/3
    Jan  6 08:13:35  EX2300-VC kernel: tcp_timer_keep:Local(0x80000001:6985) Foreign(0x80000011:56254)
    Jan  6 08:13:36  EX2300-VC l2cpd[4503]: Root bridge in routing-instance 'default' changed from 4096:44:aa:50:0e:56:02 to 32768:f4:a7:39:ce:d4:89
    Jan  6 08:13:36  EX2300-VC kernel: tcp_timer_keep: Dropping socket connection due to keepalive timer expiration, idle/intvl/cnt: 100/100/5
    Jan  6 08:13:36  EX2300-VC kernel: tcp_timer_keep:Local(0x80000001:6157) Foreign(0x80000011:62713)
    Jan  6 08:13:36  EX2300-VC kernel: tcp_timer_keep: Dropping socket connection due to keepalive timer expiration, idle/intvl/cnt: 100/100/6
    Jan  6 08:13:36  EX2300-VC kernel: tcp_timer_keep:Local(0x80000001:15001) Foreign(0x80000006:63209)
    Jan  6 08:13:43  EX2300-VC ppmd[4496]: PPMD: Connection Shutdown/Closed with  PFE: fpc1 
    Jan  6 08:13:43  EX2300-VC kernel: tcp_timer_keep: Dropping socket connection due to keepalive timer expiration, idle/intvl/cnt: 60/60/20
    Jan  6 08:13:43  EX2300-VC kernel: tcp_timer_keep:Local(0x80000001:6011) Foreign(0x80000011:64858)
    Jan  6 08:13:45  EX2300-VC kernel: tcp_timer_keep: Dropping socket connection due to keepalive timer expiration, idle/intvl/cnt: 1000/100/5
    Jan  6 08:13:45  EX2300-VC kernel: tcp_timer_keep:Local(0x80000001:33015) Foreign(0x80000011:56222)
    Jan  6 08:13:51  EX2300-VC kernel: tcp_timer_keep: Dropping socket connection due to keepalive timer expiration, idle/intvl/cnt: 100/100/20
    Jan  6 08:13:51  EX2300-VC kernel: tcp_timer_keep:Local(0x80000001:6234) Foreign(0x80000011:63593)
    Jan  6 08:13:51  EX2300-VC kernel: peer_input_pending_internal: 5649: peer class: 0, type: 27, index: 1, vksid: 0, state: 1 reported a so_error 60
    Jan  6 08:13:51  EX2300-VC kernel: peer_input_pending_internal: 5649: peer class: 0, type: 27, index: 1, vksid: 0, state: 1 reported a so_error 60
    Jan  6 08:13:51  EX2300-VC kernel: peer_inputs: 5911: VKS0 closing connection peer class: 0, type: 27, index: 1, vksid: 0, state: 1, err 5
    Jan  6 08:13:51  EX2300-VC kernel: tcp_timer_keep: Dropping socket connection due to keepalive timer expiration, idle/intvl/cnt: 100/100/20
    Jan  6 08:13:51  EX2300-VC kernel: tcp_timer_keep:Local(0x80000001:6234) Foreign(0x80000005:56944)
    Jan  6 08:13:51  EX2300-VC kernel: peer_input_pending_internal: 5649: peer class: 1, type: 7, index: 1, vksid: 0, state: 1 reported a so_error 60
    Jan  6 08:13:51  EX2300-VC kernel: peer_input_pending_internal: 5649: peer class: 1, type: 7, index: 1, vksid: 0, state: 1 reported a so_error 60
    Jan  6 08:13:51  EX2300-VC kernel: peer_inputs: 5911: VKS0 closing connection peer class: 1, type: 7, index: 1, vksid: 0, state: 1, err 5
    Jan  6 08:14:00  EX2300-VC chassisd[4439]: CHASSISD_IPC_CONNECTION_DROPPED: Dropped IPC connection for FPC 1
    Jan  6 08:14:00  EX2300-VC chassisd[4439]: CHASSISD_IFDEV_DETACH_FPC: ifdev_detach_fpc(1)
    Jan  6 08:14:00  EX2300-VC l2cpd[4503]: Root bridge in routing-instance 'default' changed from 32768:f4:a7:39:ce:d4:89 to 4096:44:aa:50:0e:56:02
    Jan  6 08:14:00  EX2300-VC l2cpd[4503]: ROOT_PORT: for Instance 0 in  routing-instance default Interface ae0.0

    Please tell me why there is a denial of service in a virtual chassis EX2300 listed on the logs.


    #EX2300virtualchassis
    #rootchange
    #TCPkeepalive


  • 2.  RE: On switch EX2300 there is failure of the virtual chassis?

     
    Posted 01-08-2020 17:41

    Hi Dmitriy MT,

     

     Checking your logs, I do not see DDoS messages, however it looks connection with FPC1 is dropping as well as STP TCN from root f4:a7:39:ce:d4:89 to 44:aa:50:0e:56:02.

     

      Depending on the amount of TCN under "show spanning-tree bridge" and log messages, high CPU issues may be also reported as the switch needs to recalculate STP again. Hence affecting connectivity with other members of the VC. You may want to investigate the reason of these TCN to discard any connectivity problem between switches on the network or any possible loop.

     

     You may also want to check the physical side of the VCports to discard any hardware issue. 

     

    Best regards!

    Esteban,

     

    If this clarifies your concern, please mark as solved!



  • 3.  RE: On switch EX2300 there is failure of the virtual chassis?

    Posted 01-09-2020 01:01

    Hello egarro!

    Previously, there was a message in the log of dcbcm_drv_port_get_lipa_status on FPC1.

     

    Jan  5 15:04:11  EX2300-VC fpc1 : dcbcm_drv_port_get_lipa_status: Port Duplex get failed for port 13 error Operation timed out
    Jan  5 23:33:24  EX2300-VC fpc1 : dcbcm_drv_port_get_lipa_status: Port Duplex get failed for port 20 error Operation timed out
    Jan  6 00:10:11  EX2300-VC fpc1 : dcbcm_drv_port_get_lipa_status: Port Duplex get failed for port 6 error Operation timed out
    Jan  6 01:46:40  EX2300-VC fpc1 : dcbcm_drv_port_get_lipa_status: Port speed get failed for port 6 error Operation timed out
    Jan  6 02:22:28  EX2300-VC fpc1 : dcbcm_drv_port_get_lipa_status: Port Status get failed for port 13 error Operation timed out
    Jan  6 08:13:21  EX2300-VC mib2d[4488]: SNMP_TRAP_LINK_DOWN: ifIndex 650, ifAdminStatus up(1), ifOperStatus down(2), ifName ge-1/0/29
    Jan  6 08:13:25  EX2300-VC mib2d[4488]: SNMP_TRAP_LINK_UP: ifIndex 650, ifAdminStatus up(1), ifOperStatus up(1), ifName ge-1/0/29
    Jan  6 08:13:35  EX2300-VC kernel: tcp_timer_keep: Dropping socket connection due to keepalive timer expiration, idle/intvl/cnt: 300/100/3
    Jan  6 08:13:35  EX2300-VC kernel: tcp_timer_keep:Local(0x80000001:6985) Foreign(0x80000011:56254)
    

     And log by STP bridge

    show spanning-tree statistics bridge
    
    
    STP Context  : default
    STP Instance : 0
    Number of Root Bridge Changes: 11           Last Changed: Mon Jan  6 08:15:16 2020
    Number of Root Port Changes:   6            Last Changed: Mon Jan  6 08:15:16 2020
    Recent TC  Received:  ae0.0                 Received    : Wed Dec 11 13:30:16 2019
    


  • 4.  RE: On switch EX2300 there is failure of the virtual chassis?

     
    Posted 01-09-2020 01:42

    These error message dcbcm_drv_port_get_lipa_status  are informational and should not have any relation to the IPC connection drop.

    Is this a 2 unit VC ? If yes then try to change the VC cable.

    Also you may try to do a power cycle of the VC to stabilize it.



  • 5.  RE: On switch EX2300 there is failure of the virtual chassis?

    Posted 01-09-2020 02:37

    Hello raviky!

    Yes, it is a cluster of two units. How do power cycle?



  • 6.  RE: On switch EX2300 there is failure of the virtual chassis?

    Posted 01-09-2020 08:06

    "request system reboot" in a vc all mebers should get powerccycled with that command, although you can also specify the member you want to powercyle using "request system reboot member member-id", "request system reboot all-members" should also reboot all members in the VC



  • 7.  RE: On switch EX2300 there is failure of the virtual chassis?
    Best Answer

     
    Posted 01-09-2020 20:02

    You can try to the command "request system reboot all-members" to completely boot both the VC members. Also you may try to power off both the individual members and then wait for few seconds and then power on.



  • 8.  RE: On switch EX2300 there is failure of the virtual chassis?

    Posted 01-09-2020 08:12

    based on the output it seems the master is FPC0 and FPC1 disconnected from the VC, can you confirm if FPC1 rebooted "show chassis routing-engine" will show output for bith RE's, if FPC1 rebooted we need to look at the logs for FPC1, loging into FPC1 "request session member member-id" "request session member 1" and look at the log messages for this FPC at the time of the event so we can get more info