Dat Junipers het _wel_ in hardware doen dus.
De forwarding wordt in hw gedaan. klopt. Nadat de Protocols de Routing table hebben geparsed, een subset wordt dan in de forwarding table gezet en deze is dan in de PFE gezet. Update's etc.. worden door de RE in de PFE gezet.. niks hardware .. Geen RE = geen nieuwe beslissingen meer.. Dat lijkt mij net zoveel in hw als in de Extreme's. Als je een crash van een SMM zouden hebben, zou de hardware nogsteeds alles blijven forwarden. ( been there, seen it ;-/ ) Alle BGP Peers zo dood als wat, maar de hardware bleef vrolijk doorlopen.. en aangezien de routes door een andere switch nog steeds ge-adverteerd werden, kwam het verkeer gewoon via een andere kant binnen, maar ging het nog steeds via de 'oude' weg naar buiten, bij gebrek aan ASIC's update. Ik heb in Mountaint View op de 5 day Juniper training de trainer een RE uit een M40 zien halen, waardoor er niet meer dan 2 packets verloren gingen.. impressive .. en zeker zoveel toen hij die RE er weer in stak..
Vind je? Ik kan me het debacle met Scarlet nog goed herinneren, waar Extreme uiteindelijk een Juniper heeft neerzet omdat de Extreme die ze hadden aangeboden niet deed wat beloofd was. Dat is krap aan een jaar geleden.
Het debacle met Scarlet ken ik vrij goed.. De firmware met de oplossing van het probleem was op dat moment al beschikbaar, maar door politiek bij hun intern en dingen in hun config wat niet als best-practice gezien wordt en geen standaard change policy maar een 'ad-hoc laten we wat wijzigen vandaag' policy is toen door Extreme besloten tijdelijk een Juniper M5 in te zetten. De oplossing in de interim-release is later ook in de main-stream code meegenomen. Sterker nog ... De Juniper M5 heb ik er toen zelf in opdracht van Extreme neergezet en ge-installeerd.. Met vriendelijke groeten, Erik Bais -------- I S - I N T E R N E D - S E R V I C E S - B V -------- domeinregistratie - webhosting - colocating - dedicated servers www.is.nl - info at is.nl - T: 0299-476185 Gorslaan 18 - 1441 RG - Purmerend ---------------------------------------------------------------
On Mon, 2003-09-08 at 14:57, Erik Bais wrote:
Dat Junipers het _wel_ in hardware doen dus.
De forwarding wordt in hw gedaan. klopt. Nadat de Protocols de Routing table hebben geparsed, een subset wordt dan in de forwarding table gezet en deze is dan in de PFE gezet.
Update's etc.. worden door de RE in de PFE gezet.. niks hardware ..
Geen RE = geen nieuwe beslissingen meer.. Dat lijkt mij net zoveel in hw als in de Extreme's. Als je een crash van een SMM zouden hebben, zou de hardware nogsteeds alles blijven forwarden. ( been there, seen it ;-/ )
Alle BGP Peers zo dood als wat, maar de hardware bleef vrolijk doorlopen.. en aangezien de routes door een andere switch nog steeds ge-adverteerd werden, kwam het verkeer gewoon via een andere kant binnen, maar ging het nog steeds via de 'oude' weg naar buiten, bij gebrek aan ASIC's update.
Ik heb in Mountaint View op de 5 day Juniper training de trainer een RE uit een M40 zien halen, waardoor er niet meer dan 2 packets verloren gingen.. impressive .. en zeker zoveel toen hij die RE er weer in stak..
Vind je? Ik kan me het debacle met Scarlet nog goed herinneren, waar Extreme uiteindelijk een Juniper heeft neerzet omdat de Extreme die ze hadden aangeboden niet deed wat beloofd was. Dat is krap aan een jaar geleden.
Het debacle met Scarlet ken ik vrij goed.. De firmware met de oplossing van het probleem was op dat moment al beschikbaar, maar door politiek bij hun intern en dingen in hun config wat ehhh die was er toen nog niet.
niet als best-practice gezien wordt en geen standaard change policy maar een 'ad-hoc laten we wat wijzigen vandaag' policy is toen door Extreme besloten tijdelijk een Juniper M5 in te zetten. De oplossing in de interim-release is later ook in de main-stream code meegenomen.
dat zou kunnen maar die hebik nog niet gezien
Sterker nog ... De Juniper M5 heb ik er toen zelf in opdracht van Extreme neergezet en ge-installeerd..
klopt maar die config is er niet meer :>
Met vriendelijke groeten,
Erik Bais
-------- I S - I N T E R N E D - S E R V I C E S - B V -------- domeinregistratie - webhosting - colocating - dedicated servers www.is.nl - info at is.nl - T: 0299-476185 Gorslaan 18 - 1441 RG - Purmerend --------------------------------------------------------------- _______________________________________________ NLNOG mailing list NLNOG at nlnog.net http://mailman.nlnog.net/mailman/listinfo/nlnog -- Met vriendelijke groet/With kind regards,
Marcel ten Berg Network Engineer Scarlet Internet marcel at sc-network.nl
ehhh die was er toen nog niet. dat zou kunnen maar die hebik nog niet gezien klopt maar die config is er niet meer :>
impressive.. Kan iemand aan de charter toevoegen dat er verwacht wordt dat www.leerquoten.nl verplicht gelezen dient te worden indien men onbekend is met quoten ? -Nils
On Mon, 8 Sep 2003, Nils Swart wrote:
Kan iemand aan de charter toevoegen dat er verwacht wordt dat www.leerquoten.nl verplicht gelezen dient te worden indien men onbekend is met quoten ?
Tjek! Schrijf je dat ff op, MarcoH? :) -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Mon, Sep 08, 2003 at 03:48:11PM +0200, Alex Bik wrote:
On Mon, 8 Sep 2003, Nils Swart wrote:
Kan iemand aan de charter toevoegen dat er verwacht wordt dat www.leerquoten.nl verplicht gelezen dient te worden indien men onbekend is met quoten ?
Tjek! Schrijf je dat ff op, MarcoH? :)
Niels was er mee bezig toch ? MarcoH
On Mon, Sep 08, 2003 at 03:54:05PM +0200, Niels Raijer wrote:
On Mon, Sep 08, 2003 at 03:52:09PM +0200, MarcoH wrote:
Hi,
Tjek! Schrijf je dat ff op, MarcoH? :)
Niels was er mee bezig toch ?
Binnenkort NLNOG charter borrel?
Ik weet nog wel een gezellige kroeg in Didam..... maar het zal wel weer Amsterdam worden zeker :) Dit keer bobt pim maar mooi zelf. Met vriendelijke groet, Dave Aaldering ISP Services BV mailto:dave at isp-services.nl -- tel +31(0)314-399900 http://www.isp-services.nl/ -- fax +31(0)314-399910
On Mon, 8 Sep 2003, Dave Aaldering wrote:
Ik weet nog wel een gezellige kroeg in Didam..... maar het zal wel weer Amsterdam worden zeker :)
Dit keer bobt pim maar mooi zelf.
Ook goed. Als Pim rijdt mag je mijn zolder wel misbruiken om de nacht door te brengen :) -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Mon, Sep 08, 2003 at 04:15:32PM +0200, Alex Bik wrote:
On Mon, 8 Sep 2003, Dave Aaldering wrote:
Ik weet nog wel een gezellige kroeg in Didam..... maar het zal wel weer Amsterdam worden zeker :)
Dit keer bobt pim maar mooi zelf.
Ook goed. Als Pim rijdt mag je mijn zolder wel misbruiken om de nacht door te brengen :)
... -- Bob Berisha "I route, therefore you are" "Wij doen niet aan default gateways" - anonymous engineer bij een DSL klant.
On Mon, Sep 08, 2003 at 04:22:34PM +0200, Bob Berisha wrote:
On Mon, Sep 08, 2003 at 04:15:32PM +0200, Alex Bik wrote:
On Mon, 8 Sep 2003, Dave Aaldering wrote:
Ik weet nog wel een gezellige kroeg in Didam..... maar het zal wel weer Amsterdam worden zeker :)
Dit keer bobt pim maar mooi zelf.
Ook goed. Als Pim rijdt mag je mijn zolder wel misbruiken om de nacht door te brengen :)
Hey, de bob ! Met vriendelijke groet, Dave Aaldering ISP Services BV mailto:dave at isp-services.nl -- tel +31(0)314-399900 http://www.isp-services.nl/ -- fax +31(0)314-399910
Ook goed. Als Pim rijdt mag je mijn zolder wel misbruiken om de nacht door te brengen :)
...
-- Bob Berisha "I route, therefore you are"
ITYM Ik rijdt, therefore you drink
"Wij doen niet aan default gateways" - anonymous engineer bij een DSL klant.
Goh, BGP met een DLS klant ;-) ? Boudewijn
On Mon, 8 Sep 2003, Boudewijn Visser wrote:
"Wij doen niet aan default gateways" - anonymous engineer bij een DSL klant.
Goh, BGP met een DLS klant ;-) ?
Nee, geen BGP. Ook geen ander IGP of EGP overigens. Maar toch vond de beste man dat hij geen default gw nodig had. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Mon, 8 Sep 2003, Boudewijn Visser wrote:
"Wij doen niet aan default gateways" - anonymous engineer bij een DSL klant.
Goh, BGP met een DLS klant ;-) ?
Nee, geen BGP. Ook geen ander IGP of EGP overigens. Maar toch vond de beste man dat hij geen default gw nodig had.
Compliment dat de content bij jullie interessant genoeg is dat hij de rest van het internet niet nodig heeft ;-) Boudewijn
On Mon, 8 Sep 2003, Boudewijn Visser wrote:
Nee, geen BGP. Ook geen ander IGP of EGP overigens. Maar toch vond de beste man dat hij geen default gw nodig had.
Compliment dat de content bij jullie interessant genoeg is dat hij de rest van het internet niet nodig heeft ;-)
De content bij de klant lokaal, want het ging over de config van z'n DSL router. Zonder default GW komt hij ook niet bij door ons gehoste content. Overigens - mocht dat nog niet duidelijk zijn - was het geen monteur van ons :) -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Mon, 8 Sep 2003, Boudewijn Visser wrote:
Nee, geen BGP. Ook geen ander IGP of EGP overigens. Maar toch vond de beste man dat hij geen default gw nodig had.
Compliment dat de content bij jullie interessant genoeg is dat hij de rest van het internet niet nodig heeft ;-)
De content bij de klant lokaal, want het ging over de config van z'n DSL router. Zonder default GW komt hij ook niet bij door ons gehoste content. Overigens - mocht dat nog niet duidelijk zijn - was het geen monteur van ons :)
ip route mailgw ip route <isp-net> ip route isp-proxy etc look ma, all the internet I need and no default ;-) Maar goed, alle kreativiteit terzijde, inderdaad een klant die je bijblijft, om te vriendelijk te zeggen. Kun je je dan voldoende bedwingen en blijven denken dat het een klant is, of geef je 'm grijnzend *exact* waar hij om vroeg ? Boudewijn
On Mon, 8 Sep 2003, Boudewijn Visser wrote:
look ma, all the internet I need and no default ;-)
:)
Kun je je dan voldoende bedwingen en blijven denken dat het een klant is, of geef je 'm grijnzend *exact* waar hij om vroeg ?
Het was geen klant. Het was een 'monteur' (bouwvakker was een betere benaming geweest) van Hebo geloof ik, die door BBNed naar de klant gestuurd was. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Mon, Sep 08, 2003 at 07:50:58PM +0200, Alex Bik wrote:
Het was geen klant. Het was een 'monteur' (bouwvakker was een betere benaming geweest) van Hebo geloof ik, die door BBNed naar de klant gestuurd was.
Baas Telematica in dit geval. De mannen van Hebo snappen het ook niet altijd, maar zien dat tenminste zelf in en nemen nog iets van je aan. "En nu tiep je cee ooo en ef spatie tee".. Overigens kwam die default route er heel snel toen onze DSL-bikkel Arjen hem belde met wat meer geduld. -- Sabri Berisha "I route, therefore you are" "Wij doen niet aan default gateways" - anonymous engineer bij een DSL klant.
On Mon, Sep 08, 2003 at 05:06:04PM +0200, Boudewijn Visser wrote:
"Wij doen niet aan default gateways" - anonymous engineer bij een DSL klant.
Goh, BGP met een DLS klant ;-) ?
DLS ?? Ohh...wacht ff http://www.dls.se/ MarcoH
On Mon, Sep 08, 2003 at 05:06:04PM +0200, Boudewijn Visser wrote:
"Wij doen niet aan default gateways" - anonymous engineer bij een DSL klant.
Goh, BGP met een DLS klant ;-) ?
DLS ?? Ohh...wacht ff http://www.dls.se/
Ja, oeps. En Ik rijdt was ook al vreselijk. Zelfs zonder een Bob nodig te hebben blunderen.... Boudewijn
On Mon, 8 Sep 2003, Erik Bais wrote:
De forwarding wordt in hw gedaan. klopt. Nadat de Protocols de Routing table hebben geparsed, een subset wordt dan in de forwarding table gezet en deze is dan in de PFE gezet.
Update's etc.. worden door de RE in de PFE gezet.. niks hardware ..
Geen RE = geen nieuwe beslissingen meer.. Dat lijkt mij net zoveel in hw als in de Extreme's.
Erik, Ik weet niet waar je al deze 'wijsheid' over Junipers vandaan hebt, maar dit is absoluut niet zoals Junipers werken. Er wordt een volledige kopie van de aktieve routetabel naar de IP2 geupload. De routing enging wordt dus absoluut _niet_ gebruikt bij het opzetten van nieuwe flows, zoals dat bij Extreme en Riverstone wel het geval is. Als je het niet geloofd, wil ik je hier met alle plezier een keer demonstreren dat jouw Extreme - net als Riverstone - helemaal dood gaat als je er pak hem beet 100 mbit aan packets in ramt met min of meer willekeurige destination addresses (zoals bij de SQL slammer), terwijl een Juniper daar niet warm of koud van wordt. Dat durf ik je zelfs te demonstreren op onze (productie draaiende) Junipers.
Het debacle met Scarlet ken ik vrij goed.. De firmware met de oplossing van het probleem was op dat moment al beschikbaar, maar door politiek bij hun intern en dingen in hun config wat niet als best-practice gezien wordt en geen standaard change policy maar een 'ad-hoc laten we wat wijzigen vandaag' policy is toen door Extreme besloten tijdelijk een Juniper M5 in te zetten. De oplossing in de interim-release is later ook in de main-stream code meegenomen.
Tuurlijk, ze hebben het gefixt. Extreme is absoluut geen kutclub! Ik haalde dit voorbeeld aan omdat de dozen zich inmiddels wel 'bewezen' hadden als layer3 device volgens jou. Daar heb ik andere ideeen over. For the record: Ik ben bijzonder tevreden over Extreme (en hun service), als layer2 device. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
Alex Bik wrote:
On Mon, 8 Sep 2003, Alex Bik wrote:
Als je het niet geloofd, wil ik je hier met alle plezier een keer
Gadverdamme! Typ ik daar een 'd' zeg.. Koffie!
Mensen... NLNOG lijkt me geen chatkanaal. Voor dat doel hou ik namelijk al weken #nlnog vrij op IRC (komt niemand opdagen trouwens). Ik krijg echt al mail genoeg en zit eerlijk gezegd niet echt te wachten op gezellig gekeuvel via deze mailinglist. Groeten, -- Marco
On Tue, 9 Sep 2003, Marco Davids (SARA) wrote:
Mensen... NLNOG lijkt me geen chatkanaal. Voor dat doel hou ik namelijk al weken #nlnog vrij op IRC (komt niemand opdagen trouwens).
Ik krijg echt al mail genoeg en zit eerlijk gezegd niet echt te wachten op gezellig gekeuvel via deze mailinglist.
Er is nog geen charter.. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Mon, Sep 08, 2003 at 03:47:09PM +0200, Alex Bik wrote:
van de aktieve routetabel naar de IP2 geupload. De routing enging wordt dus absoluut _niet_ gebruikt bij het opzetten van nieuwe flows, zoals dat bij Extreme en Riverstone wel het geval is.
Ik dacht toch echt dat juniper niet flow based was... MarcoH
On Mon, 8 Sep 2003, MarcoH wrote:
Ik dacht toch echt dat juniper niet flow based was...
Kan zijn, maar als dat al zo is, dan in ieder geval niet bestuurd vanuit het PC-tje wat er in zit. We hebben het hier getest, een Juniper tegen een Riverstone. Bij een Riverstone zie je het percentage packetloss toenemen als je bij willekeurig gekozen destination addresses de packetrate opschroeft (alles naar hetzelfde IP adres gaat wel goed), bij een Juniper maakt het niet uit of je je traffic naar 1 of meerdere IP's stuurt. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Mon, Sep 08, 2003 at 04:12:03PM +0200, Alex Bik wrote:
On Mon, 8 Sep 2003, MarcoH wrote:
Ik dacht toch echt dat juniper niet flow based was...
Kan zijn, maar als dat al zo is, dan in ieder geval niet bestuurd vanuit het PC-tje wat er in zit. We hebben het hier getest, een Juniper tegen een Riverstone. Bij een Riverstone zie je het percentage packetloss toenemen als je bij willekeurig gekozen destination addresses de packetrate opschroeft (alles naar hetzelfde IP adres gaat wel goed), bij een Juniper maakt het niet uit of je je traffic naar 1 of meerdere IP's stuurt.
Tuurlijk, maar volgens mij doet die asic van juniper gewoon voor iedere packet een lookup en zet hij geen flows op... MarcoH
On Mon, 8 Sep 2003, MarcoH wrote:
Tuurlijk, maar volgens mij doet die asic van juniper gewoon voor iedere packet een lookup en zet hij geen flows op...
In die veronderstelling was (en ben) ik ook. M'n reply was misschien een beetje vaag, maar waar het me om ging was dat het in ieder geval in hardware gebeurt, of het nu wel of niet flow based is. Flow based forwarding is eigenlijk ook alleen maar een lapmiddel voor dozen die geen route lookups in hardware kunnen. Als je lookups in hardware doet, is het bijhouden van flows volgens mij niet zo zinvol. Anyway, m'n aanbod om het te demonstreren staat :) -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Mon, 8 Sep 2003, MarcoH wrote:
Tuurlijk, maar volgens mij doet die asic van juniper gewoon voor iedere packet een lookup en zet hij geen flows op...
In die veronderstelling was (en ben) ik ook. M'n reply was misschien een beetje vaag, maar waar het me om ging was dat het in ieder geval in hardware gebeurt, of het nu wel of niet flow based is. Flow based forwarding is eigenlijk ook alleen maar een lapmiddel voor dozen die geen route lookups in hardware kunnen. Als je lookups in hardware doet, is het bijhouden van flows volgens mij niet zo zinvol.
Hardware of software heeft er niks mee te maken. De grote vraag is of er een gecached fast-path is,en een tragere situatie bij een cache miss, dan wel of de volledige forwarding table in 'cache' (cq een efficiente [qua lookup snelheid] datastructuur) staat. Of die forwarding lookup daarna door een min of meer general purpose processor dan wel een special purpose processor (aka 'asic') gedaan wordt maakt het verschil niet. Precies hetzelfde fenomeen zie je bij alle andere systemen die ergens een cache gebruiken. CPU-L1/L2/L3 cache, dram -> disk swap ,web proxy etc. Als je de pech hebt dat je toegangspatroon voortdurend de cache mist is je performance orden van groote trager dan wanneer je het merendeel van de tijd uit een cache kunt werken. Jammer voor een aantal 'L3 switch' vendors dat Internet backbone traffic (en pathologische gevallen als portscans) niet passen bij een gecached model. Cisco heeft dat ook uitgevonden, zoals te zien is in de typen forwarding. (process switching -> fast switching [cache-based], flow switching [flow based] -> cef-switching (volledige forwarding table in datastructuur). ) Boudewijn
On Mon 08 Sep 2003 (17:38 +0200), Boudewijn Visser wrote:
On Mon, 8 Sep 2003, MarcoH wrote:
Tuurlijk, maar volgens mij doet die asic van juniper gewoon voor iedere packet een lookup en zet hij geen flows op...
In die veronderstelling was (en ben) ik ook. M'n reply was misschien een beetje vaag, maar waar het me om ging was dat het in ieder geval in hardware gebeurt, of het nu wel of niet flow based is. Flow based forwarding is eigenlijk ook alleen maar een lapmiddel voor dozen die geen route lookups in hardware kunnen. Als je lookups in hardware doet, is het bijhouden van flows volgens mij niet zo zinvol.
Hardware of software heeft er niks mee te maken.
De grote vraag is of er een gecached fast-path is,en een tragere situatie bij een cache miss, dan wel of de volledige forwarding table in 'cache' (cq een efficiente [qua lookup snelheid] datastructuur) staat.
Of die forwarding lookup daarna door een min of meer general purpose processor dan wel een special purpose processor (aka 'asic') gedaan wordt maakt het verschil niet.
I beg to differ - general purpose processors don't have content addressable memory (they may in their page mapping hardware, but not for general purpose operations). Asics/dedicated routeing processors can use content addressable memory which cab be used to reduce lookup time dramatically. (for the pedants among us): I would count a general purpose processor with an attached content addressable memory as dedicated hardware -- Jim Segrave jes at nl.demon.net
On Mon 08 Sep 2003 (17:38 +0200), Boudewijn Visser wrote:
On Mon, 8 Sep 2003, MarcoH wrote:
Tuurlijk, maar volgens mij doet die asic van juniper gewoon voor iedere packet een lookup en zet hij geen flows op...
In die veronderstelling was (en ben) ik ook. M'n reply was misschien een beetje vaag, maar waar het me om ging was dat het in ieder geval in hardware gebeurt, of het nu wel of niet flow based is. Flow based forwarding is eigenlijk ook alleen maar een lapmiddel voor dozen die geen route lookups in hardware kunnen. Als je lookups in hardware doet, is het bijhouden van flows volgens mij niet zo zinvol.
Hardware of software heeft er niks mee te maken.
De grote vraag is of er een gecached fast-path is,en een tragere situatie bij een cache miss, dan wel of de volledige forwarding table in 'cache' (cq een efficiente [qua lookup snelheid] datastructuur) staat.
Of die forwarding lookup daarna door een min of meer general purpose processor dan wel een special purpose processor (aka 'asic') gedaan wordt maakt het verschil niet.
I beg to differ - general purpose processors don't have content addressable memory (they may in their page mapping hardware, but not for general purpose operations). Asics/dedicated routeing processors can use content addressable memory which cab be used to reduce lookup time dramatically.
From what I can find, Juniper also does not use CAM for storing forwarding
While I agree that special purpose hardware can (and should, what's the point otherwise) do things faster than most general purpose hw, my main point is and remains that a fast solution for cached data and a slower path for other/first time access is the culprit for the L3 switch problems. Actually, I am about 99% sure that those Extreme switches DO use asics+cam for packet forwarding, and the whole problem is that not every destination fits in that memory. Hence the caching solution, and the problem when traffic keeps thrashing the cache. For contrast, see (for example) Cisco routers with CEF enabled. Most of cisco's routers, and certainly all lower end, do not have special purpose asics. With CEF however, they DO have a fixed forwarding performance, indepedent of previous packets' destinations. (And certainly a lot faster than the rumored worst cases for some of the L3 switches. Wasn't it about 5kpps on that riverstone thingy worst case ? ) My H&P comp.arch books don't cover CAM, but some googling suggests that there are no routers yet based on a full internet forwarding table in CAM. No lack of research proposals, though. I guess that it must be hard (or *very* expensive) to build the large CAMS needed. tables, but normal DRAM and SRAM. Most switch vendors seem to use CAM indeed, but of a fairly small size. Boudewijn
Hi, CC: Phil Pennock at Demon, we were discussing this just the other day. Boudewijn wrote: | Actually, I am about 99% sure that those Extreme switches DO use asics+cam | for packet forwarding, and the whole problem is that not every destination | fits in that memory. Hence the caching solution, and the problem when | traffic keeps thrashing the cache. This is how I understood them to work, also. I'm not going to say too much about it at this point, but when I explained to Extreme folks what had happened to BIT wrt the Riverstones, they were in fact curious to see what my testbed would do to the Summit/Alpine/BlackDiamond (in that order) box. If and when I get around to an afternoon in their TAC/POClab, I'll ask them for permission to publish some 'third party results'. A careful preliminary estimation: Extreme will kick Riverstone butt, but they will not perform as well with wild L3 destinations as Cisco CEF or any Juniper. My results for Riverstone may not be flattering for them but tough luck with the shit they pulled in their aftersales 'efforts' (quote: you could always put them on ebay!). They are available on request. If anybody has an ESR/GSR left in a corner and would like to feed me coffee, I'd be very interrested in running the same test on that hardware (just as I will on Juniper and Extreme), to proove a point. | For contrast, see (for example) Cisco routers with CEF enabled. Most of | cisco's routers, and certainly all lower end, do not have special purpose | asics. | With CEF however, they DO have a fixed forwarding performance, indepedent | of previous packets' destinations. | (And certainly a lot faster than the rumored worst cases for some of the | L3 switches. Wasn't it about 5kpps on that riverstone thingy worst case ? ) Our SSR3000 maxed out at 13Kpps of UDP packets with 376 bytes of payload. The destination addresses of each packet varied with a (lousy) pseudorandom 32 bit number. | From what I can find, Juniper also does not use CAM for storing forwarding | tables, but normal DRAM and SRAM. Yes, and their IP2 processor (it's a middleway between a CPU and an ASIC) can perform several 'expensive' functions such as most specific matching and ipv4/ipv6 prefix hash lookups in constant time. This uses normal DRAM to store the tables in. AFAICR on JunOS, the frames themselves are split into 64 byte j-cells and stored in shared memory. Each incoming frame triggers a notification message to the IP2, who can then do $stuff with the packet, using its footprint already in shared memory and request an egress interface' ASIC to pick up the shattered frame and free its memory. Alternatively it can filter the packet or put it into one of N hardware WRED queues (can't remember N at the moment). The thing is, having enough fast memory to sustain 'line rate' on each interface, which can ammount to a lot with gigabit and POS cards. But in the long run, trust Juniper's statements on these matters and not mine ;) -- __________________ Met vriendelijke groet, /\ ___/ Pim van Pelt /- \ _/ Business Internet Trends BV PBVP1-RIPE /--- \/ __________________
participants (12)
-
alex＠bit.nl -
bvisser-nlnog＠xs4all.nl -
d.aaldering＠isp-services.nl -
erik＠is.nl -
jes＠nl.demon.net -
marcel＠sc-network.nl -
marco＠sara.nl -
marcoh＠marcoh.net -
niels＠nl.demon.net -
nils.swart＠attorn.nl -
pim＠bit.nl -
sabri＠cluecentral.net