Switching

Hi Experts, i am planning deployment of QFX 3000-M. Found few excellent online support , even for control plan (EX 4200 24T switches) configuration file is available just copy, paste and control plane is ready. I found configuration file a bit hard to understand (specially due to inclusion of groups etc). What i have decided to follow the control plan cabling scheme as per Juniper recommendation but change control plane configuration. I will establish  a virtual chassis consists of two EX 4200,

ge-0/0/0 and ge-1/0/0  connected to node-0 and configured as ae0 (mtu 9216 and vlan-id xxx dot1q-tunneling enabled)

ge-0/0/1 and ge-1/0/1  connected to node-1 and configured as ae1 (mtu 9216 and vlan-id xxx dot1q-tunneling enabled)

 

and so on for all nodes

 

ge-0/0/16 and ge-1/0/16  connected to IC-1 and configured as ae7 (mtu 9216 and vlan-id xxx dot1q-tunneling enabled)

ge-0/0/17 and ge-1/0/17  connected to IC-2 and configured as ae8 (mtu 9216 and vlan-id xxx dot1q-tunneling enabled)

 

ge-0/0/20 , ge-0/0/21, ge-1/0/20, ge-1/0/21  connected to DG0 and configured as ae9 (mtu 9216 and vlan-id xxx dot1q-tunneling enabled, LACP active)

 

ge-0/0/22 , ge-0/0/23, ge-1/0/22, ge-1/0/23  connected to DG1 and configured as ae10 (mtu 9216 and vlan-id xxx dot1q-tunneling enabled, LACP active)

Now you see deviation from Juniper configuration for control plane. But i think it is easy to understand the configuration in this way, manage and trouble shoot control plane.  Need comments from experts  , what adverse effects may this deviation cause on operation of QFX-3000M in production network

 

 

I would run your changes by your Juniper rep first.

 

if memory serves, the control plane network config and even patching scheme of that network has to be exact or Juniper does not support it.

 

will

Simply use the provided configuration files for the control plane and follow the instructions for patching.  Nothing goes into the control plane except the fabric devices (QFX switches, interconnects, directors).  Once the provided configuration is applied, you won't need to log in and configure them again.

Basically, if you don't completely understand the how the control plane operates attempting to deviate from the provided configurations is simply begging for a problem to occur.  Start with what is provided and get it working before changing things. 

 

-Chad

 

Hi, experts thanks a lot for attention, I tried my VC concept for control plane but it only ended with frustration and mess. All nodes , interconnect devices were visible through fabric administrative inventory command. But fte ports between nodes devices and interconnect devices were not behaving , Some times fte (Interconnect Devices) interface status LED on and link LED blinking and interface LED for fte down on node devices. Some time fte LED were up on both sides but node devices interfaces were not visible in show interface terse command output. Then i decided to go with out virtual chassis and it started functioning normally. Can some one tell what was exact issue , what i guess it is virtual chassis protocol inside EX 4200, because Interconnect Devices were also being show as Virtual Chassis  Device in show fabric administrative inventory status

The fabric is designed to have two independent control planes: control plane 0 and control plane 1.  That's why each fabric device has a c0 and c1 port.  c0 goes to plane 0, and c1 goes to plane 1.  When you used a VC configuration you merged the control planes.  Exactly what happens in that state I can't say but based on your experience it obviously doesn't work as it should.

 

-Chad

Prior to implementing our fabric we briefly considered the vc concept for the control network. As everyone points out above.. C0 and C1 need separation. In addition the base architecture must match juniper guidelines or Jtac will have issues supporting your environment.