[j-nsp] Design issue when dual homing customer edge equipment to 2 different pop locations

[Haynes, Matthew]

I will have to try that one again. The only other issue would be if a customer had 2 links into the same aggregation switch ( which happens with Metro Ethernet more than not due to geographic location ). I would kill both uplinks from two different locations even though only one location had a fiber cut.

I had thought about running more than 1 uplink from the aggregation switch to the MX routers but that drives the cost per port up dramatically. That being said I won't throw that idea out of the mix.

Thank you for the idea, I will test it and see if it would work at least for some of the scenario's we have in the field.

Matt

-----Original Message-----
From: Peter Krupl [mailto:Peter.Krupl at siminn.dk] 
Sent: Tuesday, March 13, 2012 10:11 AM
To: Haynes, Matthew
Subject: RE: Design issue when dual homing customer edge equipment to 2 different pop locations

Hi,

I have looked at CFM for exactly this scenario, and it seemed to work as expected. However I did
not verify if the mac table was flushed. But you can absolutely use CFM on a subinterface.



Med venlig hilsen

Peter Krupl

Netværksspecialist
Operations Development

Kundeservice +45 7026 2300
Fax +45 7026 2301

Siminn Danmark A/S

Stationsparken 25 . 2600 Glostrup . Danmark . siminn.dk


> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-
> bounces at puck.nether.net] On Behalf Of Haynes, Matthew
> Sent: 12. marts 2012 20:50
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] Design issue when dual homing customer edge equipment to
> 2 different pop locations
> 
> Hi All,
> 
> What I'm facing is an issue getting a vpls mac table to flush.
> 
> Our typical design with a protected ethernet service would be a customer
> edge device ( or devices ) with dual fiber connections up to two separate pop
> locations. The pop's themselves always have an aggregation switch with
> 10Gbps link ( or links depending on bandwidth etc ) up to a MX router. The
> MX uses vpls to carry the ethernet service across the mpls core and out to
> the other end of the customer circuit. The vpls circuit is tied to a logical unit
> on the MX's 10Gbps interface. This would be a single vlan/evc handoff to the
> customer. ( I have a visio diagram and a jpg image of the design but I can't
> post to the thread with the attachment on the email )
> 
> The problem I'm facing is with vpls mac flushing. If I lose a link between the
> customer edge device and the aggregation switch, the vpls mac tables don't
> know to flush on the MX routers causing it not to fail over in a timely fashion.
> 
> What I've attempted to get working in the lab is as follows.
> 
> MSTP on the MX router is physical interface based, this is due to several
> customers riding the same physical 10G link from the aggregation switch up
> to the MX itself.
> 
> ERP won't work due to version/compatibility issues between the MX and any
> aggregation switch and or CPE we currently use.
> 
> 802.1ag / CFM won't work because it's also tied to the physical interface and I
> cannot knock down the entire 10G link between  the aggregation switch and
> the MX due to other customer traffic across the same link. Also, tying this to
> the VPLS session won't work since a lot of the time there is another circuit
> from the same customer homed into the aggregation switch. If I knock down
> the whole vpls session anything homed to that particular pop for that
> customer goes down. ( if I'm not thinking of something with this technology
> please let me know )
> 
> Any and all suggestions are certainly appreciated and I look forward to
> hearing other possible solutions. If I've missed anything when using the
> above technologies please let me know.
> 
> Thanks to all of you in advance.
> 
> Matt
> 
> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp