Junos OS

Hi

Every scenario I see with Junos MC-LAG requires a ICL link and the MC-AE interface has to be L2.  If you want L3 you need to back this off to a irb interface.

I have the situation where I need to achieve the following:

multiple downstream devices, each using the same two vlan IDs.  but each ae interface uses a different L3 subnet on vlans.

example:

client 1:

vlan 10 = 10.1.1.2/30

vlan 20 = 10.2.1.2/30

client 2:

vlan 10 = 10.1.1.6/30

vlan 20 = 10.2.1.6/30

on my MC-LAG peers I want to put all vlan 10 interfaces into one L3VPN and all vlan 20 interfaces into another L3VPN.

on my cisco boxes I have mc-lag in active/standby and the following type of config:

int gi1
  lacp fast
  bundle id AAA active

int gi1.10 
  vrf forwarding L3VPN-A
  ipv4 address 10.1.1.2/30

int gi1.20
   vrf forwarding L3VPN-B
   ipv4 address 10.2.1.2/30

int gi2
  lacp fast
  bundle id BBB active

int gi2.10
  vrf forwarding L3VPN-A
  ipv4 address 10.1.1.6/30
 
int gi1.20
   vrf forwarding L3VPN-B
   ipv4 address 10.2.1.6/30

now as the Cisco is running active/standby only the active router is announcing the routes into the VRF.

on my Junos MX platforms I am wondering if I can do the same.

all examples seem to indicate I need to backoff the L3 interfaces onto IRBs.  This for me means the following complications:

1.  having to dedicate a VLAN per downlink vlan so that I can have the unique /30 subnets.

2.  having to have vlan rewrites from the internal vlans down to the standardised vlans facing the clients.

3.  having to place all of those internal vlans onto the ICL interface.

I can understand that if I wanted an active/active setup with state sync etc I may need to do these tricks, but is it needed for active/standby?

many thanks

Hello,

I'll give it a stab 

---

@William.jackson@gibtele.com wrote:

Hi

 

Every scenario I see with Junos MC-LAG requires a ICL link 

---

Technically ICL is only required for A/A MC-LAG. This is spelled out in Juniper MC-LAG tech doc

https://www.juniper.net/documentation/en_US/junos/topics/concept/mc-lag-feature-summary-best-practices.html

The interchassis link (ICL), also known as the interchassis link-protection link
(ICL-PL), is used to forward data traffic across the MC-LAG peers. This link
provides redundancy when a link failure (for example, an MC-LAG trunk failure)
occurs on one of the active links.

"one of the active" means both legs of the MC-LAG are active, a.k.a. A/A MC-LAG.

In A/S MC-LAG, You certainly can live without ICL  but ask Yourself a question - what would You do if later on Your design changes and You suddenly need A/A MC-LAG? Scramble to invest in ICL pronto? What if MC-LAG peers are dozens of miles apart?

---

@William.jackson@gibtele.com wrote:

Hi

 

 If you want L3 you need to back this off to a irb interface.

 

 

---

On MX series, You can use L3 subinterfaces with A/S MC-LAG in JUNOS 11.4R6 and later, this was fixed via confidential PR 804507.

For A/A MC-LAG, on all platforms, you still need IRB with VRRP.

HTH

Thx

Alex

HI,

Have you guys tested failing over by shutting down the ICL interface? The mc-lag member port of the peer PE goes down alone with the ICL interface. However, the "status-control standby" interface stays down and I have to bounce it to bring it back up

Thanks,

M