Switching

Hello all,

We have two point-to-point circuits for another vendor which we are currently using in an aggregated bundle.

We're having difficulty running LACP across the links.

The circuits are certified MEF "E-Line", and we have confirmed we are seeing LACP PDUs across the links.

The difficulty is one side (a) is "untagged", i.e.packets egress our switch with only our C/S-VLANS tagged, and one side (b) is "tagged", i.e. we have to strip the service providers S-VLAN to expose our C/S-VLANs underneath.

In order to do this we had to install an interrim switch so the service providers VLAN(s) can be stripped on egress from this switch.

Therefore, the topolgy is as follows :

       <Service provider network>
(a)   /                          \  (b)        (c)
EX4200                            EX4200 === SRX550
      \                          /
       <Service provider network>

We're running the aggregated bundle then from the SRX (c) to the EX (a), through the interrim EX (b).

The bundle is working just fine, but when adding LACP the DPUs don't get forwarded by the interrim switch (b).

We can't use L2PT as this has to be added to an SVLAN, and there is no SVLAN at the (a) end.

We have verified the service provider tunnels the PDUs unaltered through the link, i.e. it doesn't make use of any encapsulation or temporary mac address to identify them, it just add's their SVLAN and forwards them.

We would also like to run STP across the aggregated link, but suspect we're going to hit the same issue with the BPDUs. During a maintenance window coming up shortly I'm going to try disabling ALL STPs on the four interfaces involved on the interrim switch (b), and hope then the BPDUs will be forwarded instead of them being processed by (b). I'm sceptical as (b) isn't running any kind of LACP, yet these PDUs were not forwarded...

Anybody got any ideas of something to try? Can't imagine we're the only users of third-party links for aggregation...

Thanks in advance!

That doesn't seem right.  The point of the S-VLAN is that it is for the Service Provider to define VLAN separation within their domain, not pass the S-VLAN to the customer.  You are now, in effect, participating in their VLAN topology.  Have you spoken to your ISP about this?

Hey,

Thanks for replying!

Yes, they're our national carrier and tell me this is always how they provision these e-line links. They are subject to regulators and maintain any changes to the way this circuit is provided will involve applying to the regulator for approval etc...

They seemed pretty convinced of the need to provision the circuit this way!

Found this definition here : https://www.metroethernetforum.org/Assets/Technical_Specifications/PDF/MEF_33.pdf

The relevant part is at the bottom of page 13 and reads :

This service can provide a high degree of transparency for Frames between the EIs it interconnects such that the Frame’s header and payload upon ingress at the UNI is delivered unchanged to the ENNI, with the addition of an S-VLAN tag.The Frame's header and payload upon ingress at the ENNI is delivered unchanged to the UNI except for the removal of the S-VLAN tag.

That sounds exactly like what our service provider is doing here...

Actually, I interpret that differently.  The S-VLAN is added upon ingress and removed upon egress from their network.  That said, I believe what you're saying.

If the EX4200 is the only switch you have, I am not sure that there's much that can be done.  EX4200 supports a minimal amount of VLAN translation and I'm not sure that even the support it provides in that area is enough to get what you want. Without knowing all the details, you may be able to do an access port towards your SRX with a dot1q-tunnel port towards the ISP, but push a VLAN onto it.  I have my doubts that this is really what you are looking for, though, but perhaps it will push you in the right direction:

http://kb.juniper.net/InfoCenter/index?page=content&id=KB16755&cat=JUNOS_EX&actp=LIST&smlogin=true

Sorry, I don't think that there are specific examples using the 'push' operation.  If I come up with anything else, I'll let you know.

Is your AE between the 2 x 4200s as depicted?

When trying to add LACP between these 2 switches across SP network I doubt LACP will work as SP usually blocks these, as your connection is via their network switches, not dark fiber.  LACPDU uses a well known multicast MAC - 01-80-C2-00-00-02 for destination address.  Most switches are configured to send these packets to Control Plane (CPU).  So most times LACP will not work across SP network.  You should re-check with your SP that they pass unmodified LACPDU.

Not really sure what you mean by one-side is tagged, one side is untagged, but in generally LACPDU would be transmitted with no 802.1q tag.  Like on native VLAN.

Now if you are expecting to run AE (802.3ad) with LACP from the SRX to EX4200 (a) then this will NEVER work.  LACP is designed to only work on pt-to-pt direct attached links.  You could run LACP from Ex4200 (a) to EX4200 (b) if SP allows and then a different LACP connection from EX4200 (b) to the SRX.  What will not happen is that if one link drops say between EX4200 (b) and the SRX, this would affect the AE/LAG between the EX4200s over the SP network.

Now if you have STP enabled at the interface level for any AE/LAG then STP functions for the AE - like there is one link.  In some implemenations, STP PDUs are sent on only one link of the AE.  Not 100% sure how Juniper implements this but i suspect someone smarter than me on this forum does know.

One more thing.  When i worked for Nortel, now Avaya, we created a proprieatry off-shoot to LACP, which was called VLACP.  This used a different MAC destination MAC - one that would pass through other switches/networks.  This allowed end-to-end (vs pt-to-pt) LACP type of circuit checking.  As well if one AE/802.3ad with LACP has a link failure, the total circuit, that is end to end, should stay up.  The potential issue is oversubscription (and potential packet loss) on the AE/802.3ad with LACP connection that now has less links, and/or bandwidth.

Hopefullly this help and good luck.

If the SP has L2PT running, there should be no reason the OPs LACP won't work over the SP network, assuming the technology in use on their end is q-in-q.  But as you mentioned, the frames need to be passed as untagged to the end device. His problem is that the SP is not removing the S-VLAN upon handoff to him. 

evt, you're absolutely right, and you have the exact problem. At one end that is exactly the behaviour and (a) sees nothing of the serviceprovider VLANs, but we have to deal with it at (b)...

We have the AE running successfully between the SRX (c) and the EX4200 (a) using the exact methodology you have described. The problem is from time to time the service provider will perform maintenance on one of the links in the bundle (and they're not great at informing us in advance) so without LACP to detect which members of the bundle aren't operating we affectively lose the bundle.

//rccpgm actually we have this schema running in the lab successfully using an extra EX4200 between (a) and (b) to simulate the service providers device on the UNI (a) side, and with l2pt running on the SVLAN between the additional interrim switch(aa) and (b) LACP comes up between (a) and (c) no problem.

That lab topology is like this :

               <Serviceprovider link1>
  (a)    (aa) /                       \  (b)     (c)
EX4200==EX4200                         EX4200==SRX550
              \                       /
               <Serviceprovider link1>

The issue we have is that the service provider tunnels the PDUs "transparently" it doesn't translate the PDU MAC unlike the junos implementation of l2pt, so I can't use l2pt on (b) to translate the frames back.

I suppose what I really need is a way to make (b) ignore (ie not process) the LACP and STP PDUs and forward them downstream to the SRX and upstream on to the service providers network. Not running LACP doesn't seem to do the trick as the PDUs leave (a) and are seen on a packet capture connected where (b) is (albeit tagged with the SVLAN of the circuit), but when operating, they never make it past (b) to the SRX...

It's too bad that the SRX550 can't specify a simple input-vlan-map and output-vlan-map like the MX, or you could pop the S-VLAN right at the SRX and not worry about the EX4200 being in the way.

Another (more costly) option would be to get a device that can pop that tag off and pass the frames transparently to your SRX.  There are a number of layer 2 ethernet NID devices that could do this.  The Accedian EtherNID could do it, as could something like the Transition Networks S3290 NID.  I think Accedian even makes NIDs that are in an SFP form factor that can plug directly into your device.  Other vendors you might want to look at would be MRV and IMCNetworks (now B&B Electronics).  Or do a Google search for "ethernet demarcation device".  

We're going to be replacing this SRX with a 1400 shortly, so that may well be an option now as the SRX1400 is much closer to the MX in configuration terms...

In the meantime I'm going to give something else a go.

I need to install an additional switch at the UNI end anyway, so, if the service provider is sending the frames across transparently, but I have the problem where the EX will only forward PDUs if it is running L2PT, then it ocurred to me all I needed was to create and additional S-VLAN between the new switch (aa in the lab topology above and the new topology attached below) and the EX at the E-NNI end and run l2pt on the new VLAN between them...

I'm labbing this up anyway and will update this thread for any googlers out there.....

The port labelling above is like this :

T for Trunk or A for Access

after the hyphen is the VLAN the port is T or A in relation to, so T-S1 is a trunk port for SVLAN 1, A-E2 is an access port for Extra (service provider) VLAN 2 etc.

Fingers crossed!

So you're just doing a physical loopback on your switch?  Dang, I was going to suggest that, but wasn't sure it would really work.  Let us know your results and good luck!

Hi Eric,

Early indications aren't good...

I've got packet captures and am seeing the PDUs as far as the T-S(1/2) interfaces (running L2PT on the SVLANs at this level), but it looks like as soon as we try and push the second SVLAN (at the A-E(1/2) ports) the PDUs are lost as they'#re not seen on the T-E(1/2) interfaces...

Still trying... If I just *just* get an EX to ignore PDUs we'd be laughing!!

Hi Eric (and any googlers out there...)

I've finally solved this problem (or rather, I think I have, will confirm next week...).

After a configuration change this morning we're now (for the first time) successfully seeing MSTP BDPUs find there way across this aggregated link through the interrim switch to the two end points.

The solution was to disable igmp-snooping on the interrim switch, thus allowing the switch to forward/broadcast any multicast PDUs it wasn't interested in (all flavours of spanning tree were disabled on the switch).

I would expect this same config would allow LACP PDUs also to make it through this switch, I wasn't able to try this this morning as if it didn't work it would bring the aggregated bundle down temporarily and so I need to plan a maintenance window, but I'll be labbing this up this week and should be able to confirm...

Just thought you might be interested!

Kind regards....

No dice I'm afraid...

Whilst STP PDUs make it through the interrim switch, LACP PDUs do not.

In a lab set-up this comes up (for the first time since trying this) when layer-2-protocol-tunneling is enabled on the interrim switches, but not without it, and as we only have access to one end of the SVLAN in the production link, enabling it isn't an option here...

Back to the drawing board...

Will keep pluggin away and add results here as and when, if anybody has any ideas how to get over this last hump I'll try anything!

Cheers./C.

Finally got this sorted!!

To recap :

Igmp-snooping disabled on the data centre NTU switch enabled STP PDUs to go through the production network no problem. LACP PDUs were still processed instead of forwarded by the EX at the data centre end (the end the provider trunked).

The solution was to loop back the ae interface on the non(service-provider)-vlanned end, and push our own SVLAN so we could configure layer 2 protocol tunnelling.

The data centre end then gets our S-VLAN and the service provider's S-VLAN. Another loopback via service-provider acces port to our S-VLAN trunk port before finally egressing towards the SRX (where the other end of the ae is) on an "our" S-VLAN access port.

Now the ae is up and running LACP *just* in time for some service-provider maintenance taking place this evening 🙂

I'd be happy to paste the topology if anyone wants it...

Cheers./C.

Could you provide the config? 

Thanks