Virtual Chassis (VC) using extender ports (VCEP) shows members are present; but remote member interfaces are not present. So the VC is not functioning properly.
The Virtual Chassis is formed using the uplink ports (VCEP). The members are placed at geographically different locations and are connected using copper or fiber cables.
|EX-4200|<VCEP>-------------<ge-0/0/0>| EX-4200 used as L2 extender switch |<ge-0/0/1>--------------<VCEP>|EX-4200|
We have used a simple topology to replicate a typical scenario, where a customer has connected multiple members using fiber / copper links. The VCEP link is going through any L2 extender switch which is configured for default MTU, which is 1514 bytes.
Here in our test setup, the show virtual-chassis status command displays all the members; but the show interface terse command is not showing the interfaces associated with the remote end member switch.
master:0}
root> show virtual-chassis status
Virtual Chassis ID: 0a44.7446.4baf | Neighbour List |
Member ID | Status | Serial No | Model | Mastership
priority | Role | ID | Interface |
0 (FPC 0) | Prsnt | BM0208163012 | ex4200-24t | 128 | Master* | 1 | vcp-255/1/0 |
1 (FPC 1) | Prsnt | BP0209511902 | ex4200-48t | 128 | Backup | 0 | vcp-255/1/0 |
Member ID for next new member: 2 (FPC 2) |
{master:0}
root> show interfaces terse
Interface Admin Link Proto Local Remote
vcp-255/1/0 up up
vcp-255/1/0.32768 up up
ge-0/0/0 up up
ge-0/0/0.0 up up eth-switch
ge-0/0/1 up up
ge-0/0/1.0 up up eth-switch
ge-0/0/2 up up
ge-0/0/2.0 up up eth-switch
ge-0/0/3 up down
ge-0/0/19 up down
ge-0/0/19.0 up down eth-switch
ge-0/0/20 up down
ge-0/0/20.0 up down eth-switch
ge-0/0/21 up down
ge-0/0/21.0 up down eth-switch
ge-0/0/22 up down
ge-0/0/22.0 up down eth-switch
ge-0/0/23 up up
ge-0/0/23.0 up up eth-switch
vcp-0 up down
vcp-0.32768 up down
vcp-1 up down
vcp-1.32768 up down
bme0 up up
bme0.32768 up up inet 10.10.10.1/2
May 25 18:23:59 fpc1 PFEMAN disconnected; PFEMAN socket closed abruptly
May 25 18:23:59 fpc1 Routing engine PFEMAN reconnection succeeded after 1 tries
May 25 18:23:59 fpc1 PFEMAN master RE reconnection made
May 25 18:25:22 chassisd[1716]: CHASSISD_IPC_CONNECTION_DROPPED: Dropped IPC connection for FPC 1
May 25 18:25:22 chassisd[1716]: CHASSISD_IFDEV_DETACH_FPC: ifdev_detach_fpc(1)
May 25 18:25:22 chassisd[1716]: CHASSISD_SNMP_TRAP7: SNMP trap generated: FRU removal (jnxFruContentsIndex 7, jnxFruL1Index 2, jnxFruL2Index 0, jnxFruL3Index 0, jnxFruName FPC: EX4200-48T, 8 POE @ 1/*/*, jnxFruType 3, jnxFruSlot 1)
May 25 18:25:22 chassisd[1716]: CHASSISD_SNMP_TRAP7: SNMP trap generated: FRU removal (jnxFruContentsIndex 7, jnxFruL1Index 2, jnxFruL2Index 0, jnxFruL3Index 0, jnxFruName FPC: EX4200-48T, 8 POE @ 1/*/*, jnxFruType 3, jnxFruSlot 1)
May 25 18:25:23 chassisd[1716]: CHASSISD_SNMP_TRAP7: SNMP trap generated: FRU insertion (jnxFruContentsIndex 7, jnxFruL1Index 2, jnxFruL2Index 0, jnxFruL3Index 0, jnxFruName FPC: EX4200-48T, 8 POE @ 1/*/*, jnxFruType 3, jnxFruSlot 1)
May 25 18:28:59 fpc1 PFEMAN: Master socket closed May 25 18:28:59 /kernel: pfe_listener_open_timeout: Peer info msg not received May 25 18:28:59 fpc1 PFEMAN disconnected; PFEMAN socket closed abruptly May 25 18:28:59 fpc1 Routing engine PFEMAN reconnection succeeded after 1 tries
May 25 18:28:59 fpc1 PFEMAN master RE reconnection made
May 25 18:31:42 chassisd[1716]: CHASSISD_IPC_CONNECTION_DROPPED: Dropped IPC connection for FPC 1
May 25 18:31:42 chassisd[1716]: CHASSISD_IFDEV_DETACH_FPC: ifdev_detach_fpc(1)
May 25 18:31:43 chassisd[1716]: CHASSISD_SNMP_TRAP7: SNMP trap generated: FRU removal (jnxFruContentsIndex 7, jnxFruL1Index 2, jnxFruL2Index 0, jnxFruL3Index 0, jnxFruName FPC: EX4200-48T, 8 POE @ 1/*/*, jnxFruType 3, jnxFruSlot 1)
May 25 18:31:43 chassisd[1716]: CHASSISD_SNMP_TRAP7: SNMP trap generated: FRU removal (jnxFruContentsIndex 7, jnxFruL1Index 2, jnxFruL2Index 0, jnxFruL3Index 0, jnxFruName FPC: EX4200-48T, 8 POE @ 1/*/*, jnxFruType 3, jnxFruSlot 1)
May 25 18:31:43 chassisd[1716]: CHASSISD_SNMP_TRAP7: SNMP trap generated: FRU insertion (jnxFruContentsIndex 7, jnxFruL1Index 2, jnxFruL2Index 0, jnxFruL3Index 0, jnxFruName FPC: EX4200-48T, 8 POE @ 1/*/*, jnxFruType 3, jnxFruSlot 1)
May 25 18:33:59 fpc1 PFEMAN: Master socket closed May 25 18:33:59 /kernel: pfe_listener_open_timeout: Peer info msg not received May 25 18:33:59 fpc1 PFEMAN disconnected; PFEMAN socket closed abruptly
This happens when the intermediary devices in the circuit connecting the VC members do not support an MTU of 1586 bytes anywhere along the path. To verify this, try to ping across the circuit with do-not-fragment bit set and a size of 1600 bytes.
Please remove the VC configuration while testing this ping, since this test will not be possible with the partially formed VC.
|EX-4200|<ge-0/0/0-IP-192.168.1.1>------------{L2 Circuit}--------------<IP-192.168.1.2-ge-0/0/0>|EX-4200|
If this ping test is unsuccessful, then the issue is related to the MTU setting. In our example, the VCEP link is going through an L2 switch which is configured for the default MTU, which is 1514 bytes.
When the MTU is increased to 1600 bytes on the L2 switch, the interfaces of FPC1 successfully get associated with the VC.