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 

Anybody has any experience with that?


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 

> 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 Vitkovsky
IP Engineer

T: 0333 006 5936
E: adam.vitkov...@gamma.co.uk<mailto:adam.vitkov...@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:postmas...@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 
For more information please visit http://www.mimecast.com

cisco-nsp mailing list  cisco-nsp@puck.nether.net
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to