Switching

My organization regularly conducts testing to ensure that redundant links on core and access switches are working, which involves manually disconnecting certain ethernet/fiber ports configured as vc-ports. Seen below is fpc0 of an EX2200 with the vc-ports up:

show virtual-chassis vc-port
fpc0:
--------------------------------------------------------------------------
Interface Type Trunk Status Speed Neighbor
or ID (mbps) ID Interface
PIC / Port
0/46 Configured -1 Up 1000 3 vcp-255/0/46
0/47 Configured -1 Up 1000 1 vcp-255/0/47

Now here is what I need to achieve via cli. As seen below, port ge-0/0/46 (configured as vc-port) is now Down due to manual disconnection, but I don't know the specific cli command to bring it down (and also to bring it back up again).

fpc0:
--------------------------------------------------------------------------
Interface Type Trunk Status Speed Neighbor
or ID (mbps) ID Interface
PIC / Port
0/46 Configured -1 Down 1000
0/47 Configured -1 Up 1000 1 vcp-255/0/47

I previously tried "run request virtual-chassis vc-port set interface member 0 vcp-0" but I later found out that that command controls the dedicated vc-ports at the back of the switch meant specifically for stacking purposes, which is not what I need here.

So what I need to know is:

1. Commands for bringing down a PIC interface and to bring it back up

2. If the commands are different for EX2300 and EX4300 switches since we also have these in our organization.

Hi ,

you can shutdown a pic using 

request chassis pic (offline | online) fpc-slot slot-number pic-slot slot-number

https://www.juniper.net/documentation/en_US/junos/topics/reference/command-summary/request-chassis-pic.html

If this solves your problem, please mark this post as "Accepted Solution."

Shutting down the entire PIC to bring down one port is pretty extreme.

I don't know of a way in the CLI to up/down a VC port but can think of two alternatives:

1. Convert port back to a revenue port, and then bring that down. Then reverse the process to bring it back up.

2. From shell execute 'ifconfig vcp-255/0/46 down' / 'ifconfig vcp-255/0/46 up'

#2 is likely not supported by Juniper, I would test outside of production first.

Now that I look at it again, you're right. I only need one port down and asaleh's command looks like it's going to impact production ports severely. Or will it? Being rather clueless about switching in general and Juniper in particular, I now have more questions than answers:

1. Will bringing down an entire PIC cause the ports on that PIC to be completely unusable or will the other members of the stack be able to carry the traffic meant for those ports?
2. Suppose I decide to convert the vc-ports back to revenue ports in order to down/up them. When I convert them back to vc-ports, would that not require a reboot or reprovisioning of the stack?
   
   • Now that I think about it, perhaps just converting the vc-ports back to revenue ports would already satisfy my requirement that only one stack port functions at a time.
3. The end goal is simply to test whether or not the stack stays intact after failure of one of the stack interfaces (PIC slot 0 ports 46 and 47, in this case). As mentioned, we usually do this by manually disconnecting and reconnecting Ethernet cables and then validating the stack state with show virtual-chassis vc-port. Is there perhaps another alternative for us to do this?

If that is the final goal why don't you just reboot or gracefully shutdown the member?

Rebooting is also part of the procedure, but it's a distinctly separate step from testing the resiliency of the stack. This particular procedure requires me to disconnect one of the two virtual chassis ports, check if the stack is still intact, then reconnect, check and repeat with the other port, for each module in the stack. Do you happen to know if a more effective way to check stack integrity? I'd love to have another take on this situation.

---

@geno93n0 wrote:

1. Will bringing down an entire PIC cause the ports on that PIC to be completely unusable or will the other members of the stack be able to carry the traffic meant for those ports?
2. Suppose I decide to convert the vc-ports back to revenue ports in order to down/up them. When I convert them back to vc-ports, would that not require a reboot or reprovisioning of the stack?
3. The end goal is simply to test whether or not the stack stays intact after failure of one of the stack interfaces (PIC slot 0 ports 46 and 47, in this case). As mentioned, we usually do this by manually disconnecting and reconnecting Ethernet cables and then validating the stack state with show virtual-chassis vc-port. Is there perhaps another alternative for us to do this?

---

1. Yes it will—all physical ports on the PIC will be disabled.

2. It won’t — one feature of Juniper VC’s is being able to replace members on the fly. Enabling/disabling of VC-ports or adding/removing/changing members doesn’t require any reboot.

3. JUNOS doesn’t have any operational command to up/down a port so I think your only options are to delete the VC port, or down the interface in the shell. Be careful not to delete the VC-port from both members at the same time or you’ll end up with a bridging loop.

---

@smicker wrote:

---

@geno93n0 wrote:

1. Will bringing down an entire PIC cause the ports on that PIC to be completely unusable or will the other members of the stack be able to carry the traffic meant for those ports?
2. Suppose I decide to convert the vc-ports back to revenue ports in order to down/up them. When I convert them back to vc-ports, would that not require a reboot or reprovisioning of the stack?
3. The end goal is simply to test whether or not the stack stays intact after failure of one of the stack interfaces (PIC slot 0 ports 46 and 47, in this case). As mentioned, we usually do this by manually disconnecting and reconnecting Ethernet cables and then validating the stack state with show virtual-chassis vc-port. Is there perhaps another alternative for us to do this?

---

---

1. Yes it will—all physical ports on the PIC will be disabled.

2. It won’t — one feature of Juniper VC’s is being able to replace members on the fly. Enabling/disabling of VC-ports or adding/removing/changing members doesn’t require any reboot.

3. JUNOS doesn’t have any operational command to up/down a port so I think your only options are to delete the VC port, or down the interface in the shell. Be careful not to delete the VC-port from both members at the same time or you’ll end up with a bridging loop.

---

Okay, guess I have my answer then. You're right that I don't want to down my entire PIC, so my solution is going to be to just delete the vc-port, check stack integrity, and then provision it again, repeated for all the members. Probably going to have to lab this one first before bringing it into production and will need some very, VERY careful coding to script this so that it doesn't produce impactful errors. So the command for doing this would be

Thanks, I think this is going to be fine for my purposes. I have a follow-up question as well, by the way. As I mentioned, I previously tried "run request virtual-chassis vc-port set interface member 0 vcp-0 disable" and then ran "show virtual chassis vc-port" and got this result:

Interface Type Trunk Status Speed Neighbor
or ID (mbps) ID Interface
PIC / Port
vcp-0 Dedicated Absent
0/46 Configured -1 Up 1000 2 vcp-255/0/47
0/47 Configured -1 Up 1000 1 vcp-255/0/46

I ran "run request virtual-chassis vc-port set interface member 0" thinking that the port vcp-0 would disappear from the list, but it's still there. How do I remove this Absent interface?

Hi,

can you try the delete option ? it should be fine with uplink ports 

https://www.juniper.net/documentation/en_US/junos/topics/reference/command-summary/request-virtual-chassis-vc-port-uplink.html

If this solves your problem, please mark this post as "Accepted Solution."