[j-nsp] EX4200 Virtual Chassis Uplink Requirements - Extended VCT / VCCP

[Paul Zugnoni]

I don't believe an EX VC fiber port will work in James' provider-offered
VPLS scenario for the reason that VPLS uses MAC learning to operation, and
I believe the VC-ports on the EX assume a directly connected VC port from
a neighboring EX. However, if the provider was offering him a pseudo wire
service (Martini VPN, circuit cross connect), those might pass all the
EX-EX frames.

That said, I previously had a 7-member EX VC across a DWDM network that
worked fine for about 18 months (later replaced with in-house VPLS). The
longest EX-EX span was 50km (~3ms r/t). Each EX's fiber VCP port was
plugged into a client port on our optical gear so the EX's were just using
SR optics.

It had its limitations, though:
  * This was on 10.1. No ISSU available, so couldn't set a high SLA
  * No SNMP polling was available then of the fiber VC ports. If you had
issues with dirty fiber or weak signal, you'd have to find out via the CLI
(which happened to us on a different, more local implementation over
single mode).
  * Not being able to follow a route or a mac address-table to see which
inter-city link was being used to reach a particular destination

Members of the EX team were happy to hear about our setup (and that it
worked); the MX team cringed.

Paul Z




On 6/24/12 10:23 PM, "Sascha Luck" <lists at c4inet.net> wrote:

>On Sun, Jun 24, 2012 at 09:47:22PM -0700, Doug Hanks wrote:
>>The MX implementation of VCCP uses standard 802.1Q with a vlan-id of
>>4094.
>> I'm sure the EX is the same as well.  The maximum latency is 100ms.
>
>I don't know about the MX but this whitepaper:
>http://www.juniper.net/us/en/local/pdf/implementation-guides/8010045-en.pd
>f
>says that EX VC uses non-standard MAC framing. It's the only bit of
>documentation that mentiones that, though
>
>_______________________________________________
>juniper-nsp mailing list juniper-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp