I'm planning to move all of the routing to our juniper EX2200-c switches. We have 2 that are connected together in virtual chassis mode in different buildings. Because of that, I cannot have 2 default route for 2 different vlans since it's considered as 1 switch now and has only 1 routing table (if I'm wrong about anything, please correct me). The goal was to have the people in 1 building going out on the internet with their firewall and the other people in the other builder going out on their firewall in their building. Both EX2000 are connected to other switches which have a fiber between them also. Now I read about virtual routers and I think that it's what I'm looking for to solve my default route problem. I use layer3 vlans. I plan to give my 2 virtual routers an ip address in the same subnet (ex 10.0.0.1 and 10.0.0.2) I would like them to be redundent so I was thinking about adding all of my vlan interfaces in each routing-instances (ex vlan.10,vlan.11). Here is a very simple diagram
Here are my questions:
Thanks for your help !
I cannot have 2 default route for 2 different vlans since it's considered as 1 switch now and has only 1 routing table
That's correct. Your two switches will have a single control plane. One switch will be the RE, and the other will be the backup RE.
Will both VR will be able to ping each other since they are on the same subnet ?
Yes, as long as they're also in the same VLAN.
Will they try to communicate using the vcp link or will they use the other link ? I would like to use the other link, not the vcp one, to pass the traffic between them
You need to think of the two EX switch in a VC as one single switch, not two. It's like you have a chassis switch, and each physical EX2200 is a line card (FPC).
Can I have 2 virtual router on the same subnet ?
Sure, as long as you follow the best practice of having one subnet per VLAN, and one VLAN per subnet.
Can I use the default routing table (inet.0) and the virtual router at the same time ?
I'm not really sure what you mean here
In general, I wouldn't recommend using a virtual chassis across sites. As you've seen here, it complicates matters, and while you can get it to work, it will be harder to troubleshoot later. Especially of someone else needs to troubleshoot it while you're on leave (you don't want work calls while you're on holidays/vacation do you?)
I agree with Luke here, specially since running virtual routers will increase the load for the CPU of the 2200. If possible, the VC should be separated so as to have two different switches with their own routing table as you mentioned. You could run VRRP between them (requires a separate license if I recall correctly) or just have each office running their respective 0/0 route to their firewall/ISP.
This will make troubleshooting easier in the long run, since if an issue happens right now with the RE for the VC, both sides would have some impact until the cause is found, whereas having them separated would mean less downtime (only one affected site).
Yeah, VRRP does require a license on the lower end EX series.
However, it's not enforced, which means it can be deployed for trial purposes, and licensed later
I have the enhanced feature licence for both switch (EFL). So how does VRRP work ?
Also, if I use VRRP, can I have 2 default routes so that each switch will send internet traffic to their respective firewall in the respective building ?
Each switch will have its own default route to their respective firewall/ISP.
Switch-A(10.10.10.2/24)-----Virtual IP 10.10.10.1 ----- Switch-B (10.10.10.3/24)
Then, the device receiving the packets will route them to their respective firewall. You can dismantle the VC via disconnecting them from each other and do a factory reset on them.
Should I do 1 VRRP group per Vlan ? I image I must if I want different switches to ack as the "master".
Actually VRRP Group numbers are locally significant to the local VLAN so the same VRRP Group number can be assigned to all of them (unless multiple groups with a VLAN), BUT for ease in troubleshooting/etc I always suggest mapping VRRP Group number to the VLAN number being used.
I honestly didn't think about undoing the VC. I think it would simplify the whole thing. Is there a recommanded sequence on how to disable the VC without loosing 1 or both switches ?
Honestly, I've never had to undo a VC before.
If I were facing this, I would plan for after-hours work, and I would definitely take a backup before starting.
You will also need a plan. The VC is basically one switch, but soon you will have two. Are there IP's that will conflict? Hostnames to change? Take a look through your config and identify points like that.
After that, it's just removing the VC config, and reconfiguring the 'new' switch.
Oh, and testing of course.
Dismantling the VC should be the easy part. The main thing here is to plan the IPs, and make sure there is no conflict between both members as Luke pointed out and the testing.
For the dismantling or breakup, I would go with physically disconnecting the members, then on the master (let's say FPC 0) use "request virtual-chassis recycle member-id 1", so that it becomes standalone. On the backup, issue a load factory-defaults, reboot (with the fiber disconnected to it does not rejoin the VC afterwards or attempts to via autoconversion). If needed, also use "request virtual-chassis recycle member-id 0" and it should become a standalone device. Also, on both ends, request virtual-chassis delete pic-slot # port # so it can be used for interconnection.
Once the members are separated, they are working as standalone, and also their fiber connections are not virtual-chassis ports, you can configure the fiber port and interconnect them again. You could do in theory must of the work on one side of the VC (the backup, since this one will be set to factory default) and the master via OOB ssh or console.
Thanks for that info. Helps a lot in understanding how it works.
I effectively have a plan and a mapping for the new ips also. Was planning to take config backup on those switches also. Thanks for the pointers though !
I will probably follow this
https://www.juniper.net/documentation/en_US/junos/topics/example/virtual-chassis-mx-series-deleting.html to remove the virtual chassis. I know it's for a mx but I figure that it's mostly the same process for the EX.
I'm planning to remove the VC, change the IPs, setup vrrp for each vlan. As for spanning tree, I'm going to use vstp and set the vrrp master as the root bridge for each vlan and the secondary bridge for the "backup" router.
Thanks everyone for your replies.
I ended up removing the virtual chassis mode. To do that, I unplugged my vcp port, did a request system zeroize and then doing the
request virtual-chassis vc-port set interface vcp-0 disable member 1 and request virtual-chassis vc-port set interface vcp-1 disable member 1.
Then I built the network. I used VRRP for redundancy. Seems to be working well !