Re: [c-nsp] ME3600 TCAM capabilities

[Jordi Magrané Roig]

Hi Adam,

Thanks for your comment. I will try to build a demo lab with some spare ME3600 
amd test it.

Has anyone got more ideas?

Regards,

El 26/09/2016 a las 16:22, Adam Vitkovsky escribió:
> On 22/09/2016, 17:36, "cisco-nsp on behalf of Jordi Magrané Roig"  nsp-boun...@puck.nether.net on behalf of 
> jordimagr...@hotmail.com>
> wrote:
>

> 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.
>
Yes these tunnels are default MDTs and if you are using PIM SM or SSM in the 
core each PE will be root of its source-tree and member of source-tree of all 
other PEs.
But if you will use PIM BIDIR in your core (if supported), then I think there 
should be only one bidir-tree which all PEs can use to TX as well as RX 
messages.

adam


Adam Vitkovsky
IP Engineer

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


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

Re: [c-nsp] ME3600 TCAM capabilities

[Adam Vitkovsky]

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

> 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.
>
Yes these tunnels are default MDTs and if you are using PIM SM or SSM in the 
core each PE will be root of its source-tree and member of source-tree of all 
other PEs.
But if you will use PIM BIDIR in your core (if supported), then I think there 
should be only one bidir-tree which all PEs can use to TX as well as RX 
messages.

adam


Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  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 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 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ME3600 TCAM capabilities

[Spyros Kakaroukas]

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" 
 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.vitkov...@gamma.co.uk
>W: 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 
> 
>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 
>Mimecast.
>For more information please visit http://www.mimecast.com
>
>
>___
>cisco-nsp mailing list  cisco-nsp@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 rea

Re: [c-nsp] ME3600 TCAM capabilities

[Jordi Magrané Roig]

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.vitkov...@gamma.co.uk
W: 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  
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 
Mimecast.
For more information please visit http://www.mimecast.com


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

Re: [c-nsp] ME3600 TCAM capabilities

[Adam Vitkovsky]

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.vitkov...@gamma.co.uk
W:  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 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 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/