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.
On 22/09/2016, 17:36, "cisco-nsp on behalf of Jordi Magrané Roig"
<cisco-nsp-boun...@puck.nether.net on behalf of jordimagr...@hotmail.com> wrote:
>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
>Anybody has any experience with that?
>El 21/09/2016 a las 17:14, Adam Vitkovsky escribió:
>> 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
>> 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.
>T: 0333 006 5936
>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
>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
>For more information please visit http://www.mimecast.com
>cisco-nsp mailing list email@example.com
>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.
cisco-nsp mailing list firstname.lastname@example.org
archive at http://puck.nether.net/pipermail/cisco-nsp/