Sorry to bring up an old thread again, but I just remembered
that Cisco put out a so-called Label Switch Processor.
http://www.cisco.com/en/US/prod/collateral/routers/ps5763/data_sheet_c78-659947.html
The LSP (Cisco may have intended for the pun) is optimized
for CRS routers being run as pure
Do you realize that the source and destination IP address, TCP ports,
MAC addresses, and so on, are all larger than 20 bits? If the thing
can figure out how to hash on those parameters, it could also figure
out how to hash on labels.
:) If it were so easy, the next thread on EX LB wouldn't
Pavel Lunin [plu...@senetsy.ru] wrote:
Oh, yeah! This why the Juniper's bias towards top players can one day become
a banana peel.
This is of course the top of the technology curve where companies like Cisco
and Juniper cater only to the top end of the market, like hard drive
manufacturers
existing commodity chips which CAN do IP and some pretty deep hashing
already,
This is where my doubts start :) You've mentioned QFX — is there any
evidence they are much smarter in hashing than EX?
Personally my take is that PTX missed the mark as far as interesting
target customer size
hey,
Eventually someone will come along and realize that there is an untapped
market here, and then the promise of cheap label switching routers will
be fulfilled.
TBH, I haven't checked the pricing but I'd expect Brocade MLX and DellForce10
to be cheaper than C/J. I'm sure the edge
TBH, I haven't checked the pricing but I'd expect Brocade MLX
MLX(e) is an edge device and is much like MX in most things. It's cheaper
but at a cost of some features lack and few caveats. Although it's a good
product, it's not a label-oriented LSR anyway.
hey,
MLX(e) is an edge device and is much like MX in most things. It's cheaper
but at a cost of some features lack and few caveats. Although it's a good
product, it's not a label-oriented LSR anyway.
Same way MX is not ment to be used as LSR, yet everyone does that.
--
tarko
On Sun, Oct 23, 2011 at 01:20:28PM +0400, Pavel Lunin wrote:
TBH, I haven't checked the pricing but I'd expect Brocade MLX
MLX(e) is an edge device and is much like MX in most things. It's
cheaper but at a cost of some features lack and few caveats. Although
it's a good product, it's not a
hey,
The hardware functionality for label switching in MLX/XMR seems to be
fine (as far as I can tell), it's only the software that is still a
giant mess.
In other news, AMS-IX manages to use the very same boxes both very simple PE
(VPLS) and LSR. But I think we weren't discussing PE,
On Sunday, October 23, 2011 06:11:39 PM Tarko Tikan wrote:
In other news, AMS-IX manages to use the very same boxes
both very simple PE (VPLS) and LSR. But I think we
weren't discussing PE, only LSR.
The Brocade's seem to do this okay.
Our exchange point is running on MLX's that extend the
Yes you need to look into the packet a little bit to hash well, but this
isn't a difficult operation either (compared to holding a full table and
doing longest prefix lookups at any rate).
As far as I understand, it's not really correct to compare difficulty of
these two operations, since
Since many of these devices have IPv6 routing capability (with a
limited FIB size) it is certain that they can look far enough into the
packet to see as many labels as any reasonable design will require.
I'm not sure this is a correct comparison. See my reply to RAS.
I share your skeptical
Hashing ALU's life is not a peace of cake either.
OMG. Piece :) I'll never get on with English spelling.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
On Sat, Oct 22, 2011 at 08:19:33PM +0400, Pavel Lunin wrote:
As far as I understand, it's not really correct to compare difficulty
of these two operations, since they are performed by two different
units inside the chip. While label lookup instead of full IP table can
dramatically
On Sunday, October 23, 2011 06:29:08 AM Richard A
Steenbergen wrote:
Eventually someone will come along and realize that there
is an untapped market here, and then the promise of
cheap label switching routers will be fulfilled.
Not sure whether you recall Cisco's ASR14000 which never
made
On Thursday, October 20, 2011 10:32:02 PM Pavel Lunin wrote:
I meant that in order to do LB on labels alone (to have
enough of hash-keys for micro-flows), you need a large
enough set of labels in the core and more or less
uniformly distributed traffic over these labels. If you
have, say, 10
I meant that in order to do LB on labels alone (to have
enough of hash-keys for micro-flows), you need a large
enough set of labels in the core and more or less
uniformly distributed traffic over these labels. If you
have, say, 10 PoPs and 90 core tunnels, it's very
probable that 20% of them
BTW, this is why I'm quite sceptically looking at the Juniper's
marketing of Express Chip simplicity and corresponded benefits. Lower
number of transistors in the crystal, greater MTBF, blah-blah.
Because of the mentioned features, which I don't really believe Juniper
could easily throw
On Friday, October 21, 2011 06:24:53 PM Pavel Lunin wrote:
Thanks, I didn't see it. Cool idea, which allows to
signal sharing proportion from the ingress to LSRs down
the path. But, I am afraid, it's still not for the cheap
PFEs. At least it seems like that from the first glance.
It also
On Fri, Oct 21, 2011 at 6:24 AM, Pavel Lunin plu...@senetsy.ru wrote:
http://tools.ietf.org/html/draft-ietf-mpls-entropy-label-00
Keeping in mind what we discussed in the next thread, it's way too
complicated for the cheap ASICs, used in ethernet switches. Most of them, as
far as I
On Wednesday, October 19, 2011 03:14:01 PM Pavel Lunin
wrote:
Another example is LB. To make it smooth, LSR must get
quite deep bits from MPLS payload and process NH table
accordingly.
I think decent core routers do this today. We've had good
luck load sharing MPLS traffic on LDP labels
I think decent core routers do this today. We've had good
luck load sharing MPLS traffic on LDP labels alone on
various Cisco and Juniper kit, provided the IGP cost is the
same.
This is where the number of labels comes into play. If we talk about LSR for
not that huge IPS (having not that
On Thursday, October 20, 2011 04:25:02 PM Pavel Lunin wrote:
This is where the number of labels comes into play. If we
talk about LSR for not that huge IPS (having not that
much of core LSPs), I'm afraid, this can require to get
back to the old good conception of FEC per prefix :)
When we
This is where the number of labels comes into play. If we
talk about LSR for not that huge IPS (having not that
much of core LSPs), I'm afraid, this can require to get
back to the old good conception of FEC per prefix :)
When we were small and using Cisco 7200's as BGP-free core
routers, we
hey,
I meant that in order to do LB on labels alone (to have enough of
hash-keys for micro-flows), you need a large enough set of labels in the
core and more or less uniformly distributed traffic over these labels.
Or you could use additional hash-labels. Let the ingress LER do all the
Another example is LB. To make it smooth, LSR must get quite deep bits from
MPLS payload and process NH table accordingly.
In order to do things like facility protection or Option C Inter-AS VPN/VPLS
(sometimes it's not bad to stick it right to the core, say, in case of a
merge), LSR must be
On Sunday, October 16, 2011 09:56:41 AM Julien Goodwin
wrote:
I do object to the still vaporware, not due to ship
until the end of the year is closer. The main threat to
the T-series is that 10ge slowly removing the need for
Sonet/SDH,...
But on the flip side, a lot of folk are still
On Sunday, October 16, 2011 02:33:57 AM Richard A
Steenbergen wrote:
All the hardware in
the world doesn't help you if you don't have the right
software, and C/J shockingly don't want to make a $10k
box that obsoletes the need for a $1mil T-series.
I don't think it's terribly shocking :-).
On 16/10/11 16:55, Mark Tinka wrote:
and if all you need is 10g LAN-PHY the MX
with the 16-port MIC does it nicely.
There should be a newer version of this line card coming
with WAN-PHY support.
10g WAN-PHY helps, but isn't actually enough.
Some long-haul applications require actual
On Sunday, October 16, 2011 01:59:29 PM Julien Goodwin
wrote:
10g WAN-PHY helps, but isn't actually enough.
Preaching to the choir :-).
Mark.
signature.asc
Description: This is a digitally signed message part.
___
juniper-nsp mailing list
On 16/10/11 13:28, Richard A Steenbergen wrote:
snip openflow rant
Of course the traditional router vendors are also realizing that they
won't be able to compete on price given the massive volumes that third
party ASIC makers are doing, so they've already started building systems
around
On Sun, Oct 16, 2011 at 10:02 AM, Julien Goodwin
jgood...@studio442.com.au wrote:
Arista is the one company that seems poised to actually take this on and
keep coming out with good hardware, at a decent price, with a powerful,
open control plane. Their kit isn't Openflow interoperable yet that
On 10/14/2011 07:04 PM, Jeff Wheeler wrote:
On Fri, Oct 14, 2011 at 3:52 AM, Michele Bergonzoniberg...@labs.it wrote:
can only be done with TCAM. For those who want more info on this issue, this
is the very interesting reference that I received in a private email:
On Sat, Oct 15, 2011 at 11:04:37AM +0100, Phil Mayers wrote:
...whereas because ACLs are variable length, determined by customers
and possibly large, performance of a RAM-based ACL algorithm is hard
to predict, and people want predictable performance, and usually
line-rate performance.
On Sat, Oct 15, 2011 at 6:04 AM, Phil Mayers p.may...@imperial.ac.uk wrote:
...whereas because ACLs are variable length, determined by customers and
possibly large, performance of a RAM-based ACL algorithm is hard to predict,
and people want predictable performance, and usually line-rate
On Sat, Oct 15, 2011 at 02:56:01PM -0400, Jeff Wheeler wrote:
Most customers find that their Juniper boxes still operate at wire
rate even when they load up some ugly filters. On some boxes in some
cases, however, that is not true. But to generalize, M/MX does
everything with RAM,
On 16/10/11 05:33, Richard A Steenbergen wrote:
Hehe. Tag switching will make core routers really cheap, you'll have
a few really big PE routers only. Wasn't that the line we were sold
with TDP?
And they totally could be too, if anyone bothered to actually make them.
You don't even need
On Sun, Oct 16, 2011 at 12:56:41PM +1100, Julien Goodwin wrote:
What's needed is for an OEM to build a generic router chassis that has
separate control plane, power, and forwarding modules that can be
swapped as needed. Potentially ATCA might be a good platform for this
This is already
I would like to thank all the people that gave such helpful insights on
this issue.
I think Paul's detailed explanation, and the contributions kindly
provided by Chan, Will, Richard and another person in private email,
close the issue: I am reconfiguring for default routing. I hope people
On 13/10/11 20:21, Richard A Steenbergen wrote:
EX8200 uses SRAM for forwarding lookups, and TCAM for firewall
filtering. SRAM is perfectly capable of doing lookups at these speeds,
and infact is a lot more flexible than TCAM, whereas TCAM is actually
much better suited for doing high speed
Once upon a time, Phil Mayers p.may...@imperial.ac.uk said:
On that topic; I'm familiar with how TCAM can be used to accelerate
routing lookups, but less so with SRAM. Is the SRAM used to implement a
simple lookup table/tree, or does SRAM have some special properties
that enable it to do
On 10/14/11 03:08 , Phil Mayers wrote:
On 13/10/11 20:21, Richard A Steenbergen wrote:
EX8200 uses SRAM for forwarding lookups, and TCAM for firewall
filtering. SRAM is perfectly capable of doing lookups at these speeds,
and infact is a lot more flexible than TCAM, whereas TCAM is actually
On Fri, Oct 14, 2011 at 3:52 AM, Michele Bergonzoni berg...@labs.it wrote:
can only be done with TCAM. For those who want more info on this issue, this
is the very interesting reference that I received in a private email:
http://www.firstpr.com.au/ip/sram-ip-forwarding/
I wouldn't use that
Il 13/10/2011 13.31, Chen Jiang ha scritto:
AFAIK, The EX8200 use SRAM for FIB and TCAM for ACL, that's not like
EX2200/3200/4200 that use TCAM for all FIB and ACL.
You could vty to line card and try this knob and see what happened:
PFEM2(vty)# show shim route lpm-dmm-stats
Not sure to
On Thu, Oct 13, 2011 at 02:19:40PM +0200, Michele Bergonzoni wrote:
Il 13/10/2011 13.31, Chen Jiang ha scritto:
AFAIK, The EX8200 use SRAM for FIB and TCAM for ACL, that's not like
EX2200/3200/4200 that use TCAM for all FIB and ACL.
You could vty to line card and try this knob and see
On 10/13/11 12:21 , Richard A Steenbergen wrote:
On Thu, Oct 13, 2011 at 02:19:40PM +0200, Michele Bergonzoni wrote:
Il 13/10/2011 13.31, Chen Jiang ha scritto:
AFAIK, The EX8200 use SRAM for FIB and TCAM for ACL, that's not like
EX2200/3200/4200 that use TCAM for all FIB and ACL.
You could
On 13 October 2011 13:53, Paul WALL pauldotw...@gmail.com wrote:
You'll never be able to get a full table on your current cards, they're
defective, and will never be able to perform as advertised. The only
solution is to buy all new (and more expensive) cards, or stop carrying
full tables.
On 10/13/2011 04:23 PM, David Ball wrote:
On 13 October 2011 13:53, Paul WALL pauldotw...@gmail.com wrote:
You'll never be able to get a full table on your current cards, they're
defective, and will never be able to perform as advertised. The only
solution is to buy all new (and more
On 13 October 2011 14:41, Chris Morrow morr...@ops-netman.net wrote:
I can't help but wonder if perhaps Juniper just expects us to
buyI dunnoroutersto do routing. I'm not trying to justify
this is a flavor of the 'its only a TOR switch' discussion, but...
Should it not be ?
On 10/13/2011 05:51 PM, David Ball wrote:
On 13 October 2011 14:41, Chris Morrow morr...@ops-netman.net wrote:
I can't help but wonder if perhaps Juniper just expects us to
buyI dunnoroutersto do routing. I'm not trying to justify
this is a flavor of the 'its only a TOR
I think RAS probably has some insight into this, hopefully he will chime in. I
seem to recall reading somewhere (probably on this list) that by default the
FIB is somehow partitioned such that routes of certain lengths go into certain
sections of TCAM . . . perhaps you are running into that?
51 matches
Mail list logo
