[j-nsp] VPLS scalability question.. OTV answer?
chrisccnpspam2 at gmail.com
Sun Mar 27 20:57:12 EDT 2011
An Enhanced FPC is required, this is what was throwing me off. I guess I
don't know what is enhanced and what isn't, its not very clear.
I'm testing on m7i/m10i's using the non eCFEB, but I guess they are still
new enough as it seems to work without it.. As this seems to work is the
VPLS bandwidth capability now fully port-speed? Meaning I'm not limited to
any tunnel services PIC limitations?
On Sun, Mar 27, 2011 at 8:46 PM, Julien Goodwin
<jgoodwin at studio442.com.au>wrote:
> The short answer is:
> This is meant to just need recent-ish pic's facing the MPLS cloud.
> On 28/03/11 09:53, Chris Evans wrote:
> > All the communication that we've received from Juniper is that they
> > MPLS and VPLS to be their answer to Cisco's OTV. I've been researching
> > on the Juniper platforms and I cannot find any definite information as to
> > how much it can scale performance/bandwidth wise. VPLS requires either a
> > interface or a LSI interface on that hardware. The VT interfaces can only
> > obtained by hardware that can do tunnel services, and the LSI interface
> > only on the MX platforms from what I can read.
> > As tunnel PICs have limited performance and LSI interfaces 'steal'
> > 10Gig interfaces on the 10Gig MX blades (I know it won't on the GigE
> > how does Juniper expect to be able to provide high bandwidth VPLS while
> > still providing high port density? The TRIO cards have some inline
> > but does they offer these services? It seems like Juniper is expecting to
> > throw another half baked solution out there to compete with Cisco and I'm
> > not sure how they're going to scale the infrastructure. The Cisco
> > uses the built in ASIC hardware to do this and do not require ports to be
> > stolen, etc.. It really bothers me that you have to lose interfaces
> > install special hardware to do inline services, which only increases the
> > cost of the platforms drastically.
More information about the juniper-nsp