Re: [j-nsp] VPLS scalability question.. OTV answer?
Hi, On MX-Series you do not need any kind of tunnel services, nor deactivating any port. The LSIs are created on the run, and there is no limit - I have run a MX960 with 400 VPLS-Instances (independent, not vlan in a virtual switch) without any matter. Performance was almost linerate. Tom On 28.03.2011 00:53, Chris Evans wrote: All the communication that we've received from Juniper is that they perceive MPLS and VPLS to be their answer to Cisco's OTV. I've been researching VPLS 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 VT interface or a LSI interface on that hardware. The VT interfaces can only be obtained by hardware that can do tunnel services, and the LSI interface is only on the MX platforms from what I can read. As tunnel PICs have limited performance and LSI interfaces 'steal' physical 10Gig interfaces on the 10Gig MX blades (I know it won't on the GigE blades) how does Juniper expect to be able to provide high bandwidth VPLS while still providing high port density? The TRIO cards have some inline services, 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 solution 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 and/or install special hardware to do inline services, which only increases the cost of the platforms drastically. Anyone have some insight? Thanks Chris ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS scalability question.. OTV answer?
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 wrote: > The short answer is: > > http://www.juniper.net/techpubs/software/junos/junos92/swconfig-vpns/configuring-vpls-without-a-tunnel-services-pic.html > > 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 > perceive > > MPLS and VPLS to be their answer to Cisco's OTV. I've been researching > VPLS > > 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 > VT > > interface or a LSI interface on that hardware. The VT interfaces can only > be > > obtained by hardware that can do tunnel services, and the LSI interface > is > > only on the MX platforms from what I can read. > > > > As tunnel PICs have limited performance and LSI interfaces 'steal' > physical > > 10Gig interfaces on the 10Gig MX blades (I know it won't on the GigE > blades) > > how does Juniper expect to be able to provide high bandwidth VPLS while > > still providing high port density? The TRIO cards have some inline > services, > > 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 > solution > > 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 > and/or > > install special hardware to do inline services, which only increases the > > cost of the platforms drastically. > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS scalability question.. OTV answer?
The short answer is: http://www.juniper.net/techpubs/software/junos/junos92/swconfig-vpns/configuring-vpls-without-a-tunnel-services-pic.html 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 perceive > MPLS and VPLS to be their answer to Cisco's OTV. I've been researching VPLS > 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 VT > interface or a LSI interface on that hardware. The VT interfaces can only be > obtained by hardware that can do tunnel services, and the LSI interface is > only on the MX platforms from what I can read. > > As tunnel PICs have limited performance and LSI interfaces 'steal' physical > 10Gig interfaces on the 10Gig MX blades (I know it won't on the GigE blades) > how does Juniper expect to be able to provide high bandwidth VPLS while > still providing high port density? The TRIO cards have some inline services, > 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 solution > 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 and/or > install special hardware to do inline services, which only increases the > cost of the platforms drastically. signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS scalability question.. OTV answer?
Yes it does take some ports and resources to do this. $ for $ the 7K density is still much cheaper than MX though. Anyone know if VPLS will be built into EX8200 or Qfabric (doubtful) in the future? On Sun, Mar 27, 2011 at 7:14 PM, Quinn Snyder wrote: > otv requires a unique vdc (virtual context) to run, plus the desired > number of interfaces required to interconnect 'edge' with 'lan' > contexts, as there is no backplane interconnect between contexts. oh, > and vdc requires the advanced license (~$30k list). maximum number of > vdc per n7k is 4, as the vdc carves cam, tcam, mem, control-plane, etc > to each virtual context. > n7k-lic-adv + n*(sfp-10g + 10gbe interface) != free, especially when > hardware resources (t/cam) are factored on busy boxen. > > my two bits. > > q. > > -= sent via iphone. please excuse spelling, grammar, and brevity =- > > On Mar 27, 2011, at 15:59, Chris Evans wrote: > > > All the communication that we've received from Juniper is that they > perceive > > MPLS and VPLS to be their answer to Cisco's OTV. I've been researching > VPLS > > 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 > VT > > interface or a LSI interface on that hardware. The VT interfaces can only > be > > obtained by hardware that can do tunnel services, and the LSI interface > is > > only on the MX platforms from what I can read. > > > > As tunnel PICs have limited performance and LSI interfaces 'steal' > physical > > 10Gig interfaces on the 10Gig MX blades (I know it won't on the GigE > blades) > > how does Juniper expect to be able to provide high bandwidth VPLS while > > still providing high port density? The TRIO cards have some inline > services, > > 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 > solution > > 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 > and/or > > install special hardware to do inline services, which only increases the > > cost of the platforms drastically. > > > > Anyone have some insight? > > > > Thanks > > > > Chris > > ___ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS scalability question.. OTV answer?
>From what I can tell you have to enable tunnel services on the MX module itself still. If someone can advise whether it does or not that would help clear up things.. 10Gig ports on MX's on non TRIO modules are at a premium. The Trio module alone is very expensive too. I wouldn't want to lose ports to enable services such as this. Anyone can comment? On Sun, Mar 27, 2011 at 7:07 PM, Derick Winkworth wrote: > Do you have a link for documentation about the 10G interfaces? I was under > the > impression you weren't really "stealing" a 10G interface.. if you enable > tunnel > services on a 10G interface then you lose an interface, but with > no-tunnel-services I thought you didn't need to do that... > > > > > From: Chris Evans > To: juniper-nsp@puck.nether.net > Sent: Sun, March 27, 2011 5:53:14 PM > Subject: [j-nsp] VPLS scalability question.. OTV answer? > > All the communication that we've received from Juniper is that they > perceive > MPLS and VPLS to be their answer to Cisco's OTV. I've been researching VPLS > 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 VT > interface or a LSI interface on that hardware. The VT interfaces can only > be > obtained by hardware that can do tunnel services, and the LSI interface is > only on the MX platforms from what I can read. > > As tunnel PICs have limited performance and LSI interfaces 'steal' physical > 10Gig interfaces on the 10Gig MX blades (I know it won't on the GigE > blades) > how does Juniper expect to be able to provide high bandwidth VPLS while > still providing high port density? The TRIO cards have some inline > services, > 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 solution > 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 and/or > install special hardware to do inline services, which only increases the > cost of the platforms drastically. > > Anyone have some insight? > > Thanks > > Chris > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS scalability question.. OTV answer?
otv requires a unique vdc (virtual context) to run, plus the desired number of interfaces required to interconnect 'edge' with 'lan' contexts, as there is no backplane interconnect between contexts. oh, and vdc requires the advanced license (~$30k list). maximum number of vdc per n7k is 4, as the vdc carves cam, tcam, mem, control-plane, etc to each virtual context. n7k-lic-adv + n*(sfp-10g + 10gbe interface) != free, especially when hardware resources (t/cam) are factored on busy boxen. my two bits. q. -= sent via iphone. please excuse spelling, grammar, and brevity =- On Mar 27, 2011, at 15:59, Chris Evans wrote: > All the communication that we've received from Juniper is that they perceive > MPLS and VPLS to be their answer to Cisco's OTV. I've been researching VPLS > 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 VT > interface or a LSI interface on that hardware. The VT interfaces can only be > obtained by hardware that can do tunnel services, and the LSI interface is > only on the MX platforms from what I can read. > > As tunnel PICs have limited performance and LSI interfaces 'steal' physical > 10Gig interfaces on the 10Gig MX blades (I know it won't on the GigE blades) > how does Juniper expect to be able to provide high bandwidth VPLS while > still providing high port density? The TRIO cards have some inline services, > 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 solution > 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 and/or > install special hardware to do inline services, which only increases the > cost of the platforms drastically. > > Anyone have some insight? > > Thanks > > Chris > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS scalability question.. OTV answer?
Do you have a link for documentation about the 10G interfaces? I was under the impression you weren't really "stealing" a 10G interface.. if you enable tunnel services on a 10G interface then you lose an interface, but with no-tunnel-services I thought you didn't need to do that... From: Chris Evans To: juniper-nsp@puck.nether.net Sent: Sun, March 27, 2011 5:53:14 PM Subject: [j-nsp] VPLS scalability question.. OTV answer? All the communication that we've received from Juniper is that they perceive MPLS and VPLS to be their answer to Cisco's OTV. I've been researching VPLS 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 VT interface or a LSI interface on that hardware. The VT interfaces can only be obtained by hardware that can do tunnel services, and the LSI interface is only on the MX platforms from what I can read. As tunnel PICs have limited performance and LSI interfaces 'steal' physical 10Gig interfaces on the 10Gig MX blades (I know it won't on the GigE blades) how does Juniper expect to be able to provide high bandwidth VPLS while still providing high port density? The TRIO cards have some inline services, 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 solution 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 and/or install special hardware to do inline services, which only increases the cost of the platforms drastically. Anyone have some insight? Thanks Chris ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] VPLS scalability question.. OTV answer?
All the communication that we've received from Juniper is that they perceive MPLS and VPLS to be their answer to Cisco's OTV. I've been researching VPLS 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 VT interface or a LSI interface on that hardware. The VT interfaces can only be obtained by hardware that can do tunnel services, and the LSI interface is only on the MX platforms from what I can read. As tunnel PICs have limited performance and LSI interfaces 'steal' physical 10Gig interfaces on the 10Gig MX blades (I know it won't on the GigE blades) how does Juniper expect to be able to provide high bandwidth VPLS while still providing high port density? The TRIO cards have some inline services, 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 solution 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 and/or install special hardware to do inline services, which only increases the cost of the platforms drastically. Anyone have some insight? Thanks Chris ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
