Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

Virtual Chassis connectivity issues between remote locations

0

0

Article ID: KB21472 KB Last Updated: 04 Mar 2017Version: 2.0
Summary:
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.
Symptoms:

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

Log Messages related to this issue:
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 
Solution:
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.

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search