Junos OS

Hi There,

 

After analising the usage of MC-Lag I am now going to start with learning the virtual-chassis in MX.

Reading the documentation seems to me that is not possible to activate routing protocols, vrrp and configure VPLS between 2 member of a virtual-chassis.

The main reason seems to me that in a virtual-chassis there is basically only one control-plane therefore I do not see any way for the 2 members of the VC to be able to speak any routing protocol between them nor configure vrrp.

Did i get it correctly? So far i did not find any example of configuration which would fit this requirements.

 

Thank you all as usual!

Hi FabNewCert,

 

The concept of virtual chassis is to combine 2 physical chassis (router) to operate as one virtual chassis (MX-VC) .In MX-VC one router acts like virtual chassis master (VC-M) while the other router acts like virtual chassis backup (VC-B) and in case of VC-Master failover would be serviced by VC-Backup  . This concept essentially provides the same high-availability features of a single chassis and extend that into multiple chassis with every element being fully redundant.So coming to point that your understanding is correct that the MX-VC would not have the need for VRRP for the above reason which would be required when running over a pair of individual routers to provide the same high-availability feature.

 

BR,

Avinash

'Please Mark My Solution Accepted if it Helped, Kudos are also welcome'

Great, this it makes sense. Thanks.

What about the routing protocol between the 2 members of VC on MX? Is this something feasible?

Hi,

What is the requirement to run a routing protocol between the members in the same VC?

We already have VCCP(Virtual Chassis Control Protocol) which manages the MX Series Virtual Chassis and is based on IS-IS.

VCCP runs on the Virtual Chassis port interfaces and performs the following functions in the Virtual Chassis:

* Discovers and builds the Virtual Chassis topology

* Runs the mastership election algorithm to determine the Virtual Chassis master router

* Establishes the interchassis routing table to route traffic within the Virtual Chassis

Like IS-IS, VCCP exchanges link-state PDUs for each member router to construct a shortest path first (SPF) topology and to determine each member router's role (master or backup) in the Virtual Chassis. Because VCCP supports only point-to-point connections, no more than two member routers can be connected on any given Virtual Chassis port interface.

Let us know if you have any additional need that you want to achieve by running other routing protocols as these are members in the VC act as redundant pair.

Thanks and Regards,
Pradeep Kumar.

Juniper Business Use Only

Hi FabNewCert,

 

Since MX-VC acts as one virtual chassis the concept is that of a single control plane which essentially is controlled by whoever is VC-Master which implies there is no need of any protocols running between the 2 chassis . The point mentioned above for VCCP is required for working of the virtual chassis as one router but at global level no protocols run between the 2 members of VC on MX.

 

HTH

 

BR,

Avinash

'Please Mark My Solution Accepted if it Helped, Kudos are also welcome'

All valid your points.

The main reason is due to a migration from MCT brocade (similar to MC-Lag for juniper) to Juniper.

In the existing configuration I have MCT-brocade with VPLS, BGP, OSPF, VRRP running between the 2 MCT-Members.

Now, migrating from MCT-Brocade to MC-Lag or VC on MX i would like to keep the legacy design, especially the mpls due to a L3VPN already configured.

Not easy now to evaluate what is the less disruptive path to follow.

Both technologies, VC on MX or MC-Lag for Juniper have pro/drawback and for -n reasons they do not adapt properly to all the requirements.

e.g. MC-Lag active/active is good for having load-balancing for the traffic through the LAG but does not support mpls.

MC-Lag active/standby support mpls but not load-balancing for the traffic through the LAG.

VC on MX might fit but looks to me very complex in  terms of defining the Class of service for VCP assumig there is a need to do it. No vrrp will be required in this case also, but at the same time I would need to change all the existing ospf peering, bgp. Also sw upgrade for VC on MX will create downtime and seems to me there is no way to avoid it.

 

 

Hi,

That is me again 😃

I'd like advise you to think about migration to EVPN for L2VPNs and keep your L3VPN as is.

We have a number of documents which should help you to understand how to do it:

https://www.juniper.net/documentation/en_US/junos/topics/concept/data-center-interconnect-evpn-vxlan-evpn-mpls-wan-overview.html

https://www.juniper.net/uk/en/training/jnbooks/day-one/proof-concept-labs/using-ethernet-vpns/

https://www.nlogic.no/juniper-networks/bibliotek/This%20Week:%20Data%20Center%20Deployment%20with%20EVPN%20VXLAN/_/attachment/inline/1f997780-867c-4d51-a972-3723e5e14742:8fc8514701665d2e5d96256aa8231a52e951838a/TW_DCDeployment.v2.pdf