Mailing List Archive

1 2 3 4  View All
Re: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
On 11/Jul/20 20:00, Radu-Adrian FEURDEAN wrote:

>
> Hi, wasn't ASR1k a "software-based" series, with route lookups NOT done from TCAM, fib limit being the RAM, and forwarding done by homegrown QFP?
>
> I don't really recall things having changed with -HX series.

The ASR1000 line is all hardware-based.

The QFP clusters are hardware-based processors.

Mark.
_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
On 11/Jul/20 20:34, Saku Ytti wrote:

> I would say no, it was not software based, by HW. First gen QSFP or
> Popey was 400MHz (1.2GHz if you count multithreading) 40 core, 307M
> transistors, 20MB SRAM, 90nm lithography. It was tensilica platform
> (like npower) but Cisco IP.
> I think 2nd gen upped core count to 64 and frequency to 1.5GHz,
> changed to 40nm lithography and transistor count to 1.8B. Unsure what
> came after that.
>
> But what is software based and what is hardware based? To me ASR1k is
> HW based, it's an NPU box in my mind. Not having TCAM does not
> exclude box from being hardware, if not having TCAM means it's not
> hardware, then also say Juniper MX, PTX are not hardware, Cisco 8k is
> not hardware, Jericho2 isn't hardware, modern stuff tends to run off
> of DRAM, not TCAM.

Indeed.

NPU or TCAM, both provide hardware-based forwarding.

The difference comes down to flexibility vs. performance, and how far
you can push one in sacrifice for the other.

Mark.
_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
On Sun, 12 Jul 2020 at 21:30, Mark Tinka <mark.tinka@seacom.com> wrote:

> NPU or TCAM, both provide hardware-based forwarding.

This is a bit orthogonal. You can have an NPU with TCAM or NPU with
DRAM. You could also have ASIC with TCAM or ASIC with DRAM.

But if there is a clear line when a piece of hardware becomes an NPU
instead of ASIC, I don't know it. Trio and QFP are unambiguously NPUs,
is J2 still ASIC? In addition to J2 supporting NPL it has some
unassigned ALUs to add new features with 0 cost.

--
++ytti
_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
On 12/Jul/20 21:00, Saku Ytti wrote:

> This is a bit orthogonal. You can have an NPU with TCAM or NPU with
> DRAM. You could also have ASIC with TCAM or ASIC with DRAM.

Sorry, meant to say "NPU or ASIC".

The general messaging, over the years, has been that ASIC is quick but
not flexible, while NPU is flexible but can get bogged down by added
flexibility in time.

Mark.
_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
Will 'set path-color external-reach’ get support on NCS540?

> On Jul 12, 2020, at 1:25 PM, Phil Bedard <philxor@gmail.com> wrote:
>
> In XR in general we support restricting routes installed in the FIB using table-policy at various locations, but it's done across all NPUs. This specific feature mixing hi/lo FIB line cards adds another knob to tag certain routes as "external" so we can determine which prefixes to install on cards with only external TCAM.
>
> The normal table-policy command is supported on NCS540, some use them as dedicated RRs. There is a 16 (newer N540-ACC-SYS) and 32 GB (24Z8Q2C-SYS) version of the 540.
>
> Thanks,
>
> Phil
>
> ?On 7/10/20, 2:10 PM, "cisco-nsp on behalf of Jason Lixfeld" <cisco-nsp-bounces@puck.nether.net on behalf of jason@lixfeld.ca> wrote:
>
>
>
>> On Jul 10, 2020, at 2:56 AM, Mark Tinka <mark.tinka@seacom.com> wrote:
>>
>>> In the 9K days, they had SVD which did that:
>>>
>>> https://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-3/routing/configuration/guide/b_routing_cg43xcrs/b_routing_cg43xcrs_chapter_010.html#concept_8E1919490E274B9E97F527166CB6EF8A
>>>
>>> I don’t know if SVD exists for chassis based NCS5K or if SRD^h^h^htable-policy is the new that, but SVD was per-linecard. Table-policy is a BGP sub configuration, and presumably LC agnostic.
>>
>> Never heard of SVD, but I found this for the NCS5500:
>>
>> https://xrdocs.io/ncs5500/tutorials/mixing-base-and-scale-LC-in-NCS5500/
>
>
> Nice.
>
> There’s caveat at the bottom of that article that says it’s not supported on J-based FFF pizza boxes. I wonder why? I wonder if that applies to Qumran-AX a’la NCS540 too?
>
> _______________________________________________
> 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/
>
>

_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
It wouldn't be implemented on a platform that doesn't support an external TCAM. It doesn't make much sense on a fixed platform with a single NPU (really ASIC but NPU is easier to type) since all the interfaces are sharing the same FIB. We would also never mix/match NPU scale types on the same fixed platform in the case where we have multiple NPUs.

The feature doesn't really have a lot of adoption, most buy the SE line cards for roles needing higher FIB scale.

Thanks,
Phil

?On 7/12/20, 7:11 PM, "Jason Lixfeld" <jason@lixfeld.ca> wrote:

Will 'set path-color external-reach’ get support on NCS540?

> On Jul 12, 2020, at 1:25 PM, Phil Bedard <philxor@gmail.com> wrote:
>
> In XR in general we support restricting routes installed in the FIB using table-policy at various locations, but it's done across all NPUs. This specific feature mixing hi/lo FIB line cards adds another knob to tag certain routes as "external" so we can determine which prefixes to install on cards with only external TCAM.
>
> The normal table-policy command is supported on NCS540, some use them as dedicated RRs. There is a 16 (newer N540-ACC-SYS) and 32 GB (24Z8Q2C-SYS) version of the 540.
>
> Thanks,
>
> Phil
>
> ?On 7/10/20, 2:10 PM, "cisco-nsp on behalf of Jason Lixfeld" <cisco-nsp-bounces@puck.nether.net on behalf of jason@lixfeld.ca> wrote:
>
>
>
>> On Jul 10, 2020, at 2:56 AM, Mark Tinka <mark.tinka@seacom.com> wrote:
>>
>>> In the 9K days, they had SVD which did that:
>>>
>>> https://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-3/routing/configuration/guide/b_routing_cg43xcrs/b_routing_cg43xcrs_chapter_010.html#concept_8E1919490E274B9E97F527166CB6EF8A
>>>
>>> I don’t know if SVD exists for chassis based NCS5K or if SRD^h^h^htable-policy is the new that, but SVD was per-linecard. Table-policy is a BGP sub configuration, and presumably LC agnostic.
>>
>> Never heard of SVD, but I found this for the NCS5500:
>>
>> https://xrdocs.io/ncs5500/tutorials/mixing-base-and-scale-LC-in-NCS5500/
>
>
> Nice.
>
> There’s caveat at the bottom of that article that says it’s not supported on J-based FFF pizza boxes. I wonder why? I wonder if that applies to Qumran-AX a’la NCS540 too?
>
> _______________________________________________
> 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/
>
>



_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
On Mon, 13 Jul 2020 at 00:54, Mark Tinka <mark.tinka@seacom.com> wrote:

> The general messaging, over the years, has been that ASIC is quick but
> not flexible, while NPU is flexible but can get bogged down by added
> flexibility in time.

The classical view is that packet through ASIC takes constant,
invariant time, and packet through NPU takes variant time, depending
on how many instructions the NPU needs to perform for this packet.

But if that is a strict definition, then we don't really have ASICs
outside really cheap switches, as there is some programmability in all
new stuff being released. So I'm not sure what the correct definition
is.

Equally when does a software router become a hardware router? Why is
XEON not NPU but Trio is? Are there some objective facts which
differentiate CPU from NPU and NPU from ASIC?

# NPU vs CPU?
- NPU tends to have more cores than CPU
- NPU has application specific instruction set
- NPU has application specific memory interface

# NPU vs ASIC?
- ASIC does parsing and lookup in silicon, not by running a set of
instruction given by a program
- ASIC is constant time, NPU is variable time
- ASIC has many type of silicons for different function, NPU has many
identical siicons running different set of instruction depending on
packet/config



--
++ytti
_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
On 13/Jul/20 09:20, Saku Ytti wrote:

> But if that is a strict definition, then we don't really have ASICs
> outside really cheap switches, as there is some programmability in all
> new stuff being released. So I'm not sure what the correct definition
> is.

I've been thinking about this over the past 4 years, actually, and I
came to the conclusion that it was mostly championed by the 6500/7600
ASIC's, and Juniper's earlier Internet Processor I and Internet
Processor II ASIC's.

Since that time, we've asked routers to do more things beyond simple IP
packet forwarding, which has required those chips to evolve more into
NPU's than ASIC's. I'd say from around the ASR1000, MX and later, is
when we saw this shift.

So I agree with you that outside of classic Ethernet switches today, if
we have to be pedantic about what an ASIC is, we don't see them in
today's kit anymore.

But also, I have not heard any standard definition that makes NPU more
appropriate to what forwarding chips are doing today. Some vendors still
use "ASIC" and "NPU" interchangeably, depending on how old they are or
what mood they are in.

Ultimately, I'm not sure it matters that much nowadays, but I wouldn't
mind having the discussion :-).

Mark.

_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
> Mark Tinka
> Sent: Sunday, July 12, 2020 10:55 PM
>
> On 12/Jul/20 21:00, Saku Ytti wrote:
>
> > This is a bit orthogonal. You can have an NPU with TCAM or NPU with
> > DRAM. You could also have ASIC with TCAM or ASIC with DRAM.
>
> Sorry, meant to say "NPU or ASIC".
>
> The general messaging, over the years, has been that ASIC is quick but not
> flexible, while NPU is flexible but can get bogged down by added
flexibility in
> time.
>
That's basically it.
On J2 you can pretty much enable all the bells and whistles you can and
still get the same pps rate out of it as with no features enabled.
On run to completion NPUs every feature you enable costs you pps rate.

adam


_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
On Mon, 13 Jul 2020 at 12:42, <adamv0025@netconsultings.com> wrote:

> On J2 you can pretty much enable all the bells and whistles you can and
> still get the same pps rate out of it as with no features enabled.

I don't think this is strictly true, maybe it's true for several
cases. But even without recirculation, I think you can take variable
time through J2 and if you wanted, you could make it perform
pathologically poor, it is flexible enough for that. You can do a lot
of stuff on the lookup pipeline for the first 144B in J2. Then there
is the programmable elements matrix for future functions, can I put
every frame there with no cost? You can use system headers to skip
devices inside the pipeline.
It's hard for me to imagine with all this flexibility we'd still
always guarantee constant time.

J2 is much more flexible than what J1 was. But of course it's still
very much a pipeline of different types of silicons, some more some
less programmable. So I don't know.

--
++ytti
_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
Mark,

> On 13 Jul 2020, at 09:55, Mark Tinka <mark.tinka@seacom.com> wrote:
>
> On 13/Jul/20 09:20, Saku Ytti wrote:
>
>> But if that is a strict definition, then we don't really have ASICs
>> outside really cheap switches, as there is some programmability in all
>> new stuff being released. So I'm not sure what the correct definition
>> is.
>
> I've been thinking about this over the past 4 years, actually, and I
> came to the conclusion that it was mostly championed by the 6500/7600
> ASIC's, and Juniper's earlier Internet Processor I and Internet
> Processor II ASIC's.
>
> Since that time, we've asked routers to do more things beyond simple IP
> packet forwarding, which has required those chips to evolve more into
> NPU's than ASIC's. I'd say from around the ASR1000, MX and later, is
> when we saw this shift.
>
> […]

> Ultimately, I'm not sure it matters that much nowadays, but I wouldn't
> mind having the discussion :-).

I’d risk stating the obvious - technology is moving in one great sinusoidal shape. We tend to deaggregate, and then to aggregate, just to deaggregate again. The only thing that really changes is speed of those cycles.

Current trend is to simplify (Segment Routing) so there’s chance hardware of tomorrow can be less complex and do much less with faster speeds. But at some point there will be new protocols, applications, overlays and whatever, so there will be need to do more than just basics. You also can’t bet on oversimplifying things, as Juniper with PTX (for example) found out.

Do we have ASICs? Yes, they *still* usually drive fabrics, all else is essentially NPU - because it can be reprogrammed on the fly. As Saku pointed out, there’s less and less difference between modern x86 architectures and networking NPUs however and given how much different things can be easily done in software, this trend will continue to drive “cloud” applications. This should also help “simplifcation” trend, as there will be less and less dependency on the fancy “hardware” capabilities of a box.

Next wave will (are) probably photonics, moving further and further into direct feature capabilities without influencing speed-down to tackle specific feature in silicon. That will be true test to “how many features you *really* need” and great area to optimize further. Question is - how fast we’ll get there realistically with shipping products and how much it will level field vendors are playing on with Customers.


./
_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
Indeed, however one of the really handy side effects of this command is matches coloured with external-reach are still downloaded to the RIB. Of course, this technically adds no value, but if you’re passing a full BGP table to a downstream customer, it’s handy to see those routes in the RIB* as opposed to having to switch gears and look in the BGP RIB if folks are used to doing the former.

[*] To pass a full table to a downstream BGP customer on this box today, you need to filter the interesting prefixes so they aren’t downloaded into the RIB, which in turn prevent them from being programmed into the FIB.

> On Jul 12, 2020, at 10:01 PM, Phil Bedard <philxor@gmail.com> wrote:
>
> It wouldn't be implemented on a platform that doesn't support an external TCAM. It doesn't make much sense on a fixed platform with a single NPU (really ASIC but NPU is easier to type) since all the interfaces are sharing the same FIB. We would also never mix/match NPU scale types on the same fixed platform in the case where we have multiple NPUs.
>
> The feature doesn't really have a lot of adoption, most buy the SE line cards for roles needing higher FIB scale.
>
> Thanks,
> Phil
>
> ?On 7/12/20, 7:11 PM, "Jason Lixfeld" <jason@lixfeld.ca> wrote:
>
> Will 'set path-color external-reach’ get support on NCS540?
>
>> On Jul 12, 2020, at 1:25 PM, Phil Bedard <philxor@gmail.com> wrote:
>>
>> In XR in general we support restricting routes installed in the FIB using table-policy at various locations, but it's done across all NPUs. This specific feature mixing hi/lo FIB line cards adds another knob to tag certain routes as "external" so we can determine which prefixes to install on cards with only external TCAM.
>>
>> The normal table-policy command is supported on NCS540, some use them as dedicated RRs. There is a 16 (newer N540-ACC-SYS) and 32 GB (24Z8Q2C-SYS) version of the 540.
>>
>> Thanks,
>>
>> Phil
>>
>> ?On 7/10/20, 2:10 PM, "cisco-nsp on behalf of Jason Lixfeld" <cisco-nsp-bounces@puck.nether.net on behalf of jason@lixfeld.ca> wrote:
>>
>>
>>
>>> On Jul 10, 2020, at 2:56 AM, Mark Tinka <mark.tinka@seacom.com> wrote:
>>>
>>>> In the 9K days, they had SVD which did that:
>>>>
>>>> https://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-3/routing/configuration/guide/b_routing_cg43xcrs/b_routing_cg43xcrs_chapter_010.html#concept_8E1919490E274B9E97F527166CB6EF8A
>>>>
>>>> I don’t know if SVD exists for chassis based NCS5K or if SRD^h^h^htable-policy is the new that, but SVD was per-linecard. Table-policy is a BGP sub configuration, and presumably LC agnostic.
>>>
>>> Never heard of SVD, but I found this for the NCS5500:
>>>
>>> https://xrdocs.io/ncs5500/tutorials/mixing-base-and-scale-LC-in-NCS5500/
>>
>>
>> Nice.
>>
>> There’s caveat at the bottom of that article that says it’s not supported on J-based FFF pizza boxes. I wonder why? I wonder if that applies to Qumran-AX a’la NCS540 too?
>>
>> _______________________________________________
>> 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/
>>
>>
>
>
>

_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
On 13/Jul/20 12:27, ?ukasz Bromirski wrote:
> You also can’t bet on oversimplifying things, as Juniper with PTX (for example) found out.

Can you expand on this a little more?

Mark.
_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
On 13/Jul/20 12:27, ?ukasz Bromirski wrote:

> Do we have ASICs? Yes, they *still* usually drive fabrics, all else is essentially NPU - because it can be reprogrammed on the fly. As Saku pointed out, there’s less and less difference between modern x86 architectures and networking NPUs however and given how much different things can be easily done in software, this trend will continue to drive “cloud” applications. This should also help “simplifcation” trend, as there will be less and less dependency on the fancy “hardware” capabilities of a box.

I believe what is holding this back from becoming mainstream reality is
that the cloud providers are building their own swaths of software
solutions to run in x86 CPU's, and that code does not make it into the
wild to see what else can be done with it. So the general community
keeps messing about with flavour-of-the-year-SDN-thingy, until we
realize it doesn't work and we move on to yet-another concoction.

I believe if the cloud boys & girls shared more of that code so the
network operators can see what to do with it on white boxes fitted with
Broadcom (or equivalent), the rate of "simplification" could accelerate.


>
> Next wave will (are) probably photonics, moving further and further into direct feature capabilities without influencing speed-down to tackle specific feature in silicon. That will be true test to “how many features you *really* need” and great area to optimize further. Question is - how fast we’ll get there realistically with shipping products and how much it will level field vendors are playing on with Customers.

I saw a preso from a major cloud provider (their main cloud product
rhymes with the number of days in a year) around that back in San Diego,
2018, at some DWDM conference. It was scary for the Transport vendors.
That was nearly 3 years ago. It wouldn't surprise me if it's now an
in-house solution.

Mark.

_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
Mark,

> On 13 Jul 2020, at 15:55, Mark Tinka <mark.tinka@seacom.com> wrote:
>
> On 13/Jul/20 12:27, ?ukasz Bromirski wrote:
>> You also can’t bet on oversimplifying things, as Juniper with PTX (for example) found out.
> Can you expand on this a little more?

PTX was created as platform that will do only MPLS-based forwarding, with tiny IP routing table scale.
The idea was marketed as something that will get Juniper leading edge across SPs and win back accounts.


./
_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
On Mon, 13 Jul 2020 at 08:27, Saku Ytti <saku@ytti.fi> wrote:
>
> On Mon, 13 Jul 2020 at 00:54, Mark Tinka <mark.tinka@seacom.com> wrote:
>
> > The general messaging, over the years, has been that ASIC is quick but
> > not flexible, while NPU is flexible but can get bogged down by added
> > flexibility in time.
>
> The classical view is that packet through ASIC takes constant,
> invariant time, and packet through NPU takes variant time, depending
> on how many instructions the NPU needs to perform for this packet.

It's tough to make a clear line. This is roughly the definition I use
too ^, fixed vs flexible time, with the exception that some ASICs
support packet recirculation meaning overall packet processing time
increased but, technically each pass of the packet is still in fixed
time.


> But if that is a strict definition, then we don't really have ASICs
> outside really cheap switches, as there is some programmability in all
> new stuff being released. So I'm not sure what the correct definition
> is.

I would say that ASICs are fixed function single die or very small
number of tightly bound dies that have a fixed feature set. My
definition of an NPU is a collection of ASICs and/or a collection of
purpose built components, e.g. "a complex of ASICs". NPUs tend to have
a varying feature set depending on what uCode you load on them.
Although some ASICs have limited flexibility based on the uCode you
load on them, the features are more or less restricted to the burnt in
features, whereas an NPU could support radically different features
throughout their lifetime.


> Equally when does a software router become a hardware router? Why is
> XEON not NPU but Trio is? Are there some objective facts which
> differentiate CPU from NPU and NPU from ASIC?

Added inline..

> # NPU vs CPU?
> - NPU tends to have more cores than CPU
> - NPU has application specific instruction set
> - NPU has application specific memory interface
- NPUs (Trio from Juniper MX, NP3C from Cisco 7600,
Trident/Typhoon/Tomahawk from Cisco ASR9) are all *collections* of
components/chips working together (ASICs, S/D/RLD-RAM, e/i-TCAM, TOPs,
ALUs, FPGAs, CPLDs).
- CPU is more general purpose, that is why we have GPUs + GDDR for
example, to address a specific purpose the CPU is not geared towards,
equally we have NPUs to address another purpose a CPU is not geared
towards.
- CPUs are often multiple components too (processor(s), i/d-caches,
ALUs) but running generic code with a generic instruction set. The
components in the NPU run a limited and purpose specific instruction
set with a very different design (e.g. highly parallelised as you
said).

> # NPU vs ASIC?
> - ASIC does parsing and lookup in silicon, not by running a set of
> instruction given by a program
> - ASIC is constant time, NPU is variable time
> - ASIC has many type of silicons for different function, NPU has many
> identical siicons running different set of instruction depending on
> packet/config
- NPUs also have function specific silicon too e.g. TOPs (Task
Optimised Processors) which exist in ASR9K NPUs, but not in Trio, but
they also run uCode and have a very small amount of flexibility.

Cheers,
James.
_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
On Mon, 13 Jul 2020 at 09:01, Mark Tinka <mark.tinka@seacom.com> wrote:
>
>
>
> On 13/Jul/20 09:20, Saku Ytti wrote:
>
> > But if that is a strict definition, then we don't really have ASICs
> > outside really cheap switches, as there is some programmability in all
> > new stuff being released. So I'm not sure what the correct definition
> > is.
>
...
> Since that time, we've asked routers to do more things beyond simple IP
> packet forwarding, which has required those chips to evolve more into
> NPU's than ASIC's. I'd say from around the ASR1000, MX and later, is
> when we saw this shift.
>
> So I agree with you that outside of classic Ethernet switches today, if
> we have to be pedantic about what an ASIC is, we don't see them in
> today's kit anymore.

Back in the 7600s it was NPU based, and what we call NPUs today are
sometimes a collection of ASICs that form a "complex of ASICs". That
is what powered the 7600, the NP3C NPU. 7600s used a group of ASICs
working together to perform forwarding lookups, buffering, backplane
sending/receiving etc.

That's what we have in Juniper Trio / Cisco ASR9K / Nokia FPs too, a
bunch of devices, often ASICs working together. So I don't think that
we have no ASICs like in the classic Ethernet switch you mention, but
we have groups of them now with other components too, forming
something more complex.

Cheers,
James.
_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
On 13/Jul/20 19:19, ?ukasz Bromirski wrote:

> PTX was created as platform that will do only MPLS-based forwarding,
> with tiny IP routing table scale.
> The idea was marketed as something that will get Juniper leading edge across SPs and win back accounts.

Except it can do millions of routes in RIB and FIB, so...

Mark.
_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
The initial iteration of the PTX couldn't. It was really just meant as an LSR with relatively low FIB scale, couldn't do Netflow (remember the external server to do it?), etc. That quickly pivoted to something more capable. Juniper sort of positioned the initial version as a route reflector since that was one of the other things it could do due to selective FIB install.

Thanks,
Phil

?On 7/13/20, 2:36 PM, "cisco-nsp on behalf of Mark Tinka" <cisco-nsp-bounces@puck.nether.net on behalf of mark.tinka@seacom.com> wrote:


On 13/Jul/20 19:19, ?ukasz Bromirski wrote:

> PTX was created as platform that will do only MPLS-based forwarding,
> with tiny IP routing table scale.
> The idea was marketed as something that will get Juniper leading edge across SPs and win back accounts.

Except it can do millions of routes in RIB and FIB, so...

Mark.
_______________________________________________
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/


_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
On 13/Jul/20 21:51, Phil Bedard wrote:
> The initial iteration of the PTX couldn't. It was really just meant as an LSR with relatively low FIB scale, couldn't do Netflow (remember the external server to do it?), etc. That quickly pivoted to something more capable. Juniper sort of positioned the initial version as a route reflector since that was one of the other things it could do due to selective FIB install.

The PTX1000?

I somewhat recall the PTX5000 launching first, and then the smaller
variants following. But my memory isn't what it used to be.

Mark.

_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
On 13/Jul/20 21:51, Phil Bedard wrote:
> Juniper sort of positioned the initial version as a route reflector since that was one of the other things it could do due to selective FIB install.

Between the J-series router, the JCS1200 and what some customers did
with the M120, Juniper have struggled to push an RR-only box.

Thank God all the vendors found a way to virtualize their OS's :-).

Mark.
_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
The PTX 5000 was the original PTX. The 1st/2nd generation FPCs didn't have much FIB capacity, like 128k routes which was well below an Internet table in 2014. The 3rd gen is where they started supporting up to 1M+ v4 prefixes. The CSE2000 was the external appliance.

Thanks,
Phil

?On 7/13/20, 5:25 PM, "Mark Tinka" <mark.tinka@seacom.com> wrote:



On 13/Jul/20 21:51, Phil Bedard wrote:
> The initial iteration of the PTX couldn't. It was really just meant as an LSR with relatively low FIB scale, couldn't do Netflow (remember the external server to do it?), etc. That quickly pivoted to something more capable. Juniper sort of positioned the initial version as a route reflector since that was one of the other things it could do due to selective FIB install.

The PTX1000?

I somewhat recall the PTX5000 launching first, and then the smaller
variants following. But my memory isn't what it used to be.

Mark.



_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
On 14/Jul/20 04:28, Phil Bedard wrote:
> The PTX 5000 was the original PTX. The 1st/2nd generation FPCs didn't have much FIB capacity, like 128k routes which was well below an Internet table in 2014. The 3rd gen is where they started supporting up to 1M+ v4 prefixes.

Yes, this is what I remember also. But if you look at the PTX1000, you
don't have that problem from when it went into inception.

Granted, one could say Juniper made the assumption that most MPLS-based
networks would run a BGP-free core, and in theory, there were right.
What they didn't account was that 6PE was one of those "temporary
becomes permanent" situations.


> The CSE2000 was the external appliance.

Personally, I've never felt running Netflow on core routers is ideal,
particularly if you are a BGP-free core network, and if your collector
isn't that great at grabbing flow data from MPLS frames.

Mark.
_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
On Mon, 13 Jul 2020 at 20:39, James Bensley
<jwbensley+cisco-nsp@gmail.com> wrote:

> Back in the 7600s it was NPU based, and what we call NPUs today are
> sometimes a collection of ASICs that form a "complex of ASICs". That
> is what powered the 7600, the NP3C NPU. 7600s used a group of ASICs
> working together to perform forwarding lookups, buffering, backplane
> sending/receiving etc.

NP3C was on ES20+ (not ES20). The ASR9k Trident was the same EZchip
NP3C. But of course the vast majority of 7600 linecards were PFC3,
clearly not a NPU.

--
++ytti
_______________________________________________
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: Cisco N540-ACC-SYS ipv4 routes [ In reply to ]
> Mark Tinka
> Sent: Monday, July 13, 2020 3:04 PM
>
> On 13/Jul/20 12:27, ?ukasz Bromirski wrote:
>
> > Do we have ASICs? Yes, they *still* usually drive fabrics, all else is
> essentially NPU - because it can be reprogrammed on the fly. As Saku
> pointed out, there’s less and less difference between modern x86
> architectures and networking NPUs however and given how much different
> things can be easily done in software, this trend will continue to drive “cloud”
> applications. This should also help “simplifcation” trend, as there will be less
> and less dependency on the fancy “hardware” capabilities of a box.
>
> I believe what is holding this back from becoming mainstream reality is that
> the cloud providers are building their own swaths of software solutions to
> run in x86 CPU's, and that code does not make it into the wild to see what
> else can be done with it. So the general community keeps messing about
> with flavour-of-the-year-SDN-thingy, until we realize it doesn't work and we
> move on to yet-another concoction.
>
Not sure what you mean, you can run XR on a white-box, or x86-host (e.g. cRDP). -that's regarding the disaggregation and NFV...
And regarding the "flavour-of-the-year-SDN-thingy", I guess I could see how it has a certain mystery about it for outsiders, but for someone building an intent based networking/ service orchestration system all the concepts you read about in various RFCs, books and publications are a day to day reality.

> I believe if the cloud boys & girls shared more of that code so the network
> operators can see what to do with it on white boxes fitted with Broadcom (or
> equivalent), the rate of "simplification" could accelerate.
>
I'd say NO thanks very much,
Have you seen what they did with their espresso core? Looks like a bunch of programmers attempt at core network while never talking to anyone with network background, (no wonder their network architect job advert looked more like software architect job advert -not a single requirement around networking design skills).
There are a few interesting concepts in there worth exploring, but the thing is a mess.

adam


_______________________________________________
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/

1 2 3 4  View All