M20 FPC throughput
6 answers - 421 bytes -

What is the forwarding capacity of a FPC in a M20?
Is it 5Gbps, or 3.2 Gbps or 2.5 Gbps or 2.0 Gbps and any supporting
information/link will be indeed helpful
Could anyone clarify the same for M160 and M320, please?
Best,
Jimmy
Express yourself instantly with MSN Messenger! Download today it's FREE!
juniper-nsp mailing list juniper-nsp (AT) puck (DOT) nether.net
No.1 | | 984 bytes |
| 
As juniper said:
M20 SSB
System and Switch Board
25.6-Gbps throughput (12.8-Gbps full duplex)
M20
3.2-Gbps full-duplex throughput per FPC
Two enhanced I/ Manager ASICs
Parsing, prioritizing, and queuing of packets
I/ Manager memory options:
2-MB parity-protected SSRAM per I/ Manager ASIC
4-MB parity-protected SSRAM per I/ Manager ASIC (Enhanced Plus FPC)
200 ms of delay-bandwidth buffering per FPC
Regards
George
The Drifter wrote:
What is the forwarding capacity of a FPC in a M20?
Is it 5Gbps, or 3.2 Gbps or 2.5 Gbps or 2.0 Gbps and any supporting
information/link will be indeed helpful
Could anyone clarify the same for M160 and M320, please?
Best,
Jimmy
Express yourself instantly with MSN Messenger! Download today it's FREE!
juniper-nsp mailing list juniper-nsp (AT) puck (DOT) nether.net
juniper-nsp mailing list juniper-nsp (AT) puck (DOT) nether.net
No.2 | | 536 bytes |
| 
(2005-08-15 06:33 +0000), The Drifter wrote:
What is the forwarding capacity of a FPC in a M20?
Is it 5Gbps, or 3.2 Gbps or 2.5 Gbps or 2.0 Gbps and any supporting
information/link will be indeed helpful
It's exactly 4Gbps (32bit*125MHz). But J-CELL's overhead is "16/80 == 20%".
So that boils down to 4*0.2=0.8Gbps lost to J-CELLs, so 3.2 left for
packets, and this is packets, not frames, as L2 headers have been stripped
by now.
Could anyone clarify the same for M160 and M320, please?
No.3 | | 1786 bytes |
| 
Mon, Aug 15, 2005 at 10:21:38AM +0300, Saku Ytti wrote:
(2005-08-15 06:33 +0000), The Drifter wrote:
What is the forwarding capacity of a FPC in a M20?
Is it 5Gbps, or 3.2 Gbps or 2.5 Gbps or 2.0 Gbps and any supporting
information/link will be indeed helpful
It's exactly 4Gbps (32bit*125MHz). But J-CELL's overhead is "16/80 == 20%".
So that boils down to 4*0.2=0.8Gbps lost to J-CELLs, so 3.2 left for
packets, and this is packets, not frames, as L2 headers have been stripped
by now.
With the note that, like all cell technology, one byte extra on the packet
pushes you over into the next cell. That means it is probably safer to
think of it in jcells/sec, instead of bandwidth/sec.
So, if my math is right, you get 6.25M jcells/sec (32000000 bytes/sec /
512 bytes/sec/jcell) per direction per FPC. A 65 byte packet (the worst
case packet for bandwidth to jcell ratio) will burn 2 jcells, meaning that
3.125M packets/sec at 65 bytes will fill an FPC.
A 65 byte packet weighs in at 103 bytes after ethernet overhead, (8 bytes
preamble+sfd, 14 bytes for the eth header, 65 bytes for the payload, 4
bytes for the fcs, 12 bytes for the ifg), which means that you can stuff
1000Mbps / 824 bps/packet = 1.21Mpps of 65 byte packets down a GigE at
line rate.
So the big answer at the end is that it takes 2.575 GigE's sending 65 byte
packets at their line rate of 1.21Mpps each to exhaust an FPC. Feel free
to double check my math on that, it's late, but I'm pretty sure thats
right. course that is a non-realistic situation which you would only
ever encounter on a DoS attack specifically targetting Junipers, but it
helps to know what the worst case really is.
No.4 | | 1494 bytes |
| 
(2005-08-15 04:27 -0400), Richard A Steenbergen wrote:
So the big answer at the end is that it takes 2.575 GigE's sending 65 byte
packets at their line rate of 1.21Mpps each to exhaust an FPC. Feel free
to double check my math on that, it's late, but I'm pretty sure thats
right. course that is a non-realistic situation which you would only
ever encounter on a DoS attack specifically targetting Junipers, but it
helps to know what the worst case really is.
Indeed, I've done same math for GSR and JNPR also. And GSR has other
big weaknesses also, while I love the boxes in right context, they're
absolutely failure (when running IS) when it comes to protecting them,
GSR cannot be protected in acceptable way without using iACL
(which everyone in the Internet should be using, by now, instead of
bashing vendors about bugs that will always be there).
I dread the moment when script kiddies learn GSR/JNPR basics, especially
GSR, learning to put right data on the packet, it shouldn't take much
more than 350kpps to force GSR to drop all IGP etc on that interface.
rACL and CoPP shouldn't help that much, as they're done in LC CPU,
instead of ASIC, without having IS XR clues, I'd be ready to bet money
that they're done in ASIC in IS XR.
TH, this particular attack luckily isn't as powerful against GSR
as it's agaist JNPR, due to smaller cell size in GSR.
No.5 | | 266 bytes |
| 
(2005-08-15 04:27 -0400), Richard A Steenbergen wrote:
So, if my math is right, you get 6.25M jcells/sec (32000000 bytes/sec /
512 bytes/sec/jcell) per direction per FPC. A 65 byte packet (the worst
Math is right, small bytes/bits nitpick though :)
No.6 | | 857 bytes |
| 
Mon, Aug 15, 2005 at 11:53:00AM +0300, Saku Ytti wrote:
(2005-08-15 04:27 -0400), Richard A Steenbergen wrote:
So, if my math is right, you get 6.25M jcells/sec (32000000 bytes/sec /
512 bytes/sec/jcell) per direction per FPC. A 65 byte packet (the worst
Math is right, small bytes/bits nitpick though :)
Err yes, those should be bits/sec. :)
There are of course a billion different ways that kiddies could kill us
all if they had the slightest clue what they were doing. Fortunately they
don't, and it isn't a trivial attack anyways, but like I said it helps to
know where you stand when it comes to this kind of thing. Would be nice if
there was a way to display the jcell utilization numbers so those people
running 4 GE's on an FPC1 knew where they stood instead of having to
guess. :)