[c-nsp] End to end keepalive over QinQ provider

[Tim Jackson]

Cisco 7600 won't tunnel LACP.. I wouldn't say strange equipment doesn't do
it. Lots of "normal" gear sucks at it. L2PT is bad, and all of the gear is
bad (and it should feel bad).

One option would be to buy "cheap" ethenet NIDs that can do L2PT tunneling
to uncommon MAC addresses to avoid the underlying equipment from eating the
frames. Accedian/Adva/Overture/Probably others can all do that.

Ethernet CFM could potentially do what you're after, but there's not going
to be a built in mechanism to disable a port, or take a port out of the
port-channel.

Go L3 instead across your two links.


On Tue, Feb 5, 2013 at 12:23 PM, Ross Halliday <
ross.halliday at wtccommunications.ca> wrote:

> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> > bounces at puck.nether.net] On Behalf Of Chris Evans
> > Sent: Tuesday, February 05, 2013 1:19 PM
> > To: Adam Vitkovsky
> > Cc: cisco-nsp
> > Subject: Re: [c-nsp] End to end keepalive over QinQ provider
> >
> > I have two paths that I'd like to port-channel. Since they don't support
> > LACP the only thing I can do is do static configuration, but if the path
> > of
> > one of the links takes a hit there is no end to end notifications that
> > will
> > cause an interface to go down or be taken out of forwarding. With LACP
> > you
> > can do this because the ports will debundle. I was hoping that CFM would
> > take the path out of service, but I don't think that is the case.
> >
> > Thoughts?
>
> You mean the LACP negotiation is eaten by your provider? What kind of
> strange equipment/config are they running?
>
> UDLD is designed to do what you want - will that function?
>
> Cheers
> Ross
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>