[c-nsp] ME3600 TCAM capabilities

Thu Sep 22 11:09:21 EDT 2016

Hi Jordi,

That's a complex problem and if you want high scalability, ME3600 isn't really the platform for that. If you really do want something that looks like hub and spoke, you could achieve it with a hierarchical topology.

For example, you could choose a few points to deploy ME3800s or some other more scalable box, terminate pseudowires to them from the ME3600s and then have the ME3800s offer the l3vpn/mvpn services. Caveats may include decreased reliability, increased complexity and higher bandwidth utilisation among others. It's up to you to decide whether such a solution would fit your topology and requirements or not.

My thoughts and words are my own.

Spyros

On 22/09/2016, 17:36, "cisco-nsp on behalf of Jordi Magrané Roig" <cisco-nsp-bounces at puck.nether.net on behalf of jordimagrane at hotmail.com> wrote:

>Hi Adam,
>
>Thanks. Do you know exactly the commands to partitionate the TCAM?
>
>Regarding my question about the hub & spoke, I mean the GRE tunnels that are dynamically created when you enable MDT in the VRF. Now, in my network all the PE are ME3600 anf they learn the loopbacks of all other PE inside the MDT address famliy. Each PE builds one interface tunnel multipoint to all the other PE. My problem is that the ME3600 is limited to 250 MDT routes and I will have more than 250 PE in the next year.
>My idea was choose one ME3800 as a hub and all other ME3600 should have only one MDT tunnel to this ME3800. But I don't know if in MPLS this architecture works.
>
>Anybody has any experience with that?
>
>Thanks.
>
>
>El 21/09/2016 a las 17:14, Adam Vitkovsky escribió:
>Hi Jordi,
>
>> Jordi Magrané Roig
>> Sent: Wednesday, September 21, 2016 3:05 PM
>>
>> The maximum MDT routes is 250. I understand that the devices will not learn
>> more than 250 routes and then the GRE tunnels that are created to
>> encapsulate the multicast traffic will not be created anymore. Do you know if
>> there are some commands to tune the TCAM partition? Do you know if in
>
>Beauty of this platform is that anything is possible via the service cli, the problem is though that the documentation to it is sparse and decentralized even in cisco and without the right manual you won't be able to figure out how to do the TCAM partitioning, or maybe you could, if you'd have couple of these boxes you can afford to break you can exercise the trial and error approach. :)
>Anyways the ultimate problem is that all these ad-hoc tweaks will be lost after reload unless you include them into the IOS code so they can be set during booting.
>
>> MPLS environment it is possible to build the multicast tunnels as hub & spoke
>> instead of full-mesh?
>>
>Not sure what do you mean.
>You have plethora of options how to scale the MDT numbers. The drawback of scaling down the number of MDTs though is the m-cast distribution inefficiency.
>So for what it's worth you could have just one MDT tunnel if you build your default MDT using PIM BIDIR and won't allow switchover to data MDTs -but then all m-cast streams will be received by all PEs.
>Also please note that the Data MDTs will be created only from actual sources to all interested receivers -so kind of hub and spoke -if you imagine PE hosting m-cast source as hub.
>
>
>adam
>
>
>
>
>
>
>
>Adam Vitkovsky
>IP Engineer
>
>T: 0333 006 5936
>E: Adam.Vitkovsky at gamma.co.uk<mailto:Adam.Vitkovsky at gamma.co.uk>
>W: www.gamma.co.uk<http://www.gamma.co.uk>
>
>This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email <mailto:postmaster at gamma.co.uk> postmaster at gamma.co.uk<mailto:postmaster at gamma.co.uk>
>
>Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
>
>
>________________________________
>This email has been scanned for email related threats and delivered safely by Mimecast.
>For more information please visit http://www.mimecast.com
>________________________________
>
>_______________________________________________
>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/

This e-mail and any attachment(s) contained within are confidential and are intended only for the use of the individual to whom they are addressed. The information contained in this communication may be privileged, or exempt from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete the communication without retaining any copies. Connecticore SA is not responsible for, nor endorses, any opinion, recommendation, conclusion, solicitation, offer or agreement or any information contained in this communication.