On Mon, 8 Sep 2003, Boudewijn Visser wrote:
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.
Behalve dan dat het geen zin heeft om de zooi te 'cachen' als je zonder noemenswaardige vertraging een lookup per packet kan doen.
Jammer voor een aantal 'L3 switch' vendors dat Internet backbone traffic (en pathologische gevallen als portscans) niet passen bij een gecached model.
Inderdaad. Hoe je 't ook wendt of keert, je wilt een doos die vlotte route lookups kan doen. Zo vlot dat je geen 'cacheing' nodig hebt als lapmiddel om hem in bepaalde gevallen toch te laten overleven. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Mon, 8 Sep 2003, Boudewijn Visser wrote:
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.
Behalve dan dat het geen zin heeft om de zooi te 'cachen' als je zonder noemenswaardige vertraging een lookup per packet kan doen.
Het begrip 'cache' wordt inderdaad wat vreemd als je er 'alles' al in zet. Toch kun je ook een volledige forwarding table nog wel als 'cache' van een routing table beschouwen, aangezien de routing table typisch allerlei attributen bij de routes beschikbaar houdt, en de forwarding table alleen de beste routes bevat, en zonder verdere informatie daarover. Ongetwijfeld worden de forwarding table en de routing table ook in een ander soort datastructuur opgeslagen; De een voor snelle lookups, de ander bv voor meer informatie en minder geheugen gebruik.
Jammer voor een aantal 'L3 switch' vendors dat Internet backbone traffic (en pathologische gevallen als portscans) niet passen bij een gecached model.
Inderdaad. Hoe je 't ook wendt of keert, je wilt een doos die vlotte route lookups kan doen. Zo vlot dat je geen 'cacheing' nodig hebt als lapmiddel om hem in bepaalde gevallen toch te laten overleven.
Ik vermoed dat de L3 switch vendors gedwongen zijn door hun hardware om te werken met een caching model. Waarschijnlijk hebben de forwarding asics maar een beperkte hoeveelheid geheugen.(CAM, naar ik meen. Dat ook verder wat speciaal is, en 'gewoon wat dimmetjes erbij' is vast geen simpele optie, zelfs niet voor de vendor). De main CPU heeft wel meer geheugen, maar kan dus alleen maar L3 routes in het L2 geheugen stoppen, en daar is geen ruimte voor een full routing table. Je zou je kunnen afvragen of 1: l3 routes tenminste per *route* in de snelle cache passen (ipv per host) 2: hoeveel L3 routes erin passen 3: Of de software als de totale routing table klein genoeg is ze er ook allemaal meteen inzet, zonder getriggerd te worden door het eerste packet. 4: de switch dus geen enkele beperking heeft bij een stel vlannen+default gw Het zou natuurlijk ook kunnen dat de hardware geen enkel probleem is, en de L2+L3 switch vendors gewoon zijn gaan coden zonder naar de ervaring van de afgelopen 10 jaar Internet te kijken, maar dat zou wel erg dom zijn. En, eerlijk is eerlijk, een beperkt aantal routes/caching is meer dan voldoende voor enterprise en office -achtige omgevingen. Zeker geen slechte markt om in te zitten. Boudewijn
On Mon, 8 Sep 2003, Boudewijn Visser wrote:
Het begrip 'cache' wordt inderdaad wat vreemd als je er 'alles' al in zet.
Inderdaad :)
Toch kun je ook een volledige forwarding table nog wel als 'cache' van een routing table beschouwen, aangezien de routing table typisch allerlei attributen bij de routes beschikbaar houdt, en de forwarding table alleen de beste routes bevat, en zonder verdere informatie daarover.
Yep.
Je zou je kunnen afvragen of 1: l3 routes tenminste per *route* in de snelle cache passen (ipv per host) 2: hoeveel L3 routes erin passen 3: Of de software als de totale routing table klein genoeg is ze er ook allemaal meteen inzet, zonder getriggerd te worden door het eerste packet. 4: de switch dus geen enkele beperking heeft bij een stel vlannen+default gw
5: Of je wel l3 wilt doen met een doos die in beginsel voor l2 ontworpen is.
En, eerlijk is eerlijk, een beperkt aantal routes/caching is meer dan voldoende voor enterprise en office -achtige omgevingen. Zeker geen slechte markt om in te zitten.
Ik kan je een verhaal vertellen van een Riverstone RSS 3000 die jammerlijk door z'n knieen ging door de SQL slammer, terwijl er alleen een handjevol OSPF routes en een default GW in zat. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Mon, 8 Sep 2003, Boudewijn Visser wrote:
[..]
Je zou je kunnen afvragen of 1: l3 routes tenminste per *route* in de snelle cache passen (ipv per host) 2: hoeveel L3 routes erin passen 3: Of de software als de totale routing table klein genoeg is ze er ook allemaal meteen inzet, zonder getriggerd te worden door het eerste packet. 4: de switch dus geen enkele beperking heeft bij een stel vlannen+default gw
5: Of je wel l3 wilt doen met een doos die in beginsel voor l2 ontworpen is.
Wel, de afkomst doet er m.i. niet zoveel toe, het gaat erom of die doos L3 goed genoeg kan doen voor wat ik wil. (en wat ik ervoor wil betalen).
En, eerlijk is eerlijk, een beperkt aantal routes/caching is meer dan voldoende voor enterprise en office -achtige omgevingen. Zeker geen slechte markt om in te zitten.
Ik kan je een verhaal vertellen van een Riverstone RSS 3000 die jammerlijk door z'n knieen ging door de SQL slammer, terwijl er alleen een handjevol OSPF routes en een default GW in zat.
Jammer, met een handjevol routes leek me er in elk geval geen principieel probleem te zijn om met een permanent gevulde cache te werken. Ging hij overigens onderuit vanwege cache-thrashing, of te hard gehit op management adres, genereren van icmp's etc ? Ook goed bekend staande routers zijn daar (zonder maatregelen) kwetsbaar voor. Nu is slammer met of zonder crashende L3 switch een probleem in office omgevingen. (dikke db server, gbit poort, rest van lan op 10/100 . Of de L3 switch nou crasht of niet, je hebt een probleem.... ). Nou weet ik niet precies de prijzen, maar heb ik toch sterk het vermoeden dat een office/enterprise omgeving, met een stel servers aan gbit wel behoorlijk goedkoper uit is met L3 switches, dan met een juniper of cisco die de benodigde forwarding performance heeft. Alleen ISP's hebben de situatie van zo'n enorme variatie in bestemmingen als normaal gebruikelijk netwerk verkeer. (zelfs zonder slammer of portscanners) Boudewijn
On Mon, 8 Sep 2003, Boudewijn Visser wrote:
Jammer, met een handjevol routes leek me er in elk geval geen principieel probleem te zijn om met een permanent gevulde cache te werken.
Dat ligt er aan hoe de cache werkt. Het lijkt er bij de riverstones op dat de flows erin opgeslagen worden, niet de routetabel.
Ging hij overigens onderuit vanwege cache-thrashing, of te hard gehit op management adres, genereren van icmp's etc ?
Dat eerste, de packets waren niet aan hem gericht. Hij hoefde ze dus 'alleen maar' te forwarden.
Nou weet ik niet precies de prijzen, maar heb ik toch sterk het vermoeden dat een office/enterprise omgeving, met een stel servers aan gbit wel behoorlijk goedkoper uit is met L3 switches, dan met een juniper of cisco die de benodigde forwarding performance heeft.
Tuurlijk. Je zult mij ook niet horen/zien ontkennen dat die dozen goedkoper zijn. Dat is dan ook het enige voordeel. En zoals bekend heeft ieder voordeel z'n nadeel. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Mon, 8 Sep 2003, Boudewijn Visser wrote:
Jammer, met een handjevol routes leek me er in elk geval geen principieel probleem te zijn om met een permanent gevulde cache te werken.
Dat ligt er aan hoe de cache werkt. Het lijkt er bij de riverstones op dat de flows erin opgeslagen worden, niet de routetabel.
Nu ik erover nadenk (en na wat google werk bij de reply aan Jim) eigenlijk wel logisch. Het doen van een longest prefix match lijkt niet zo gebruikelijk/makkelijk te zijn voor CAM geheugen. Dus blijft het cachen van flows (mooi woord voor destination IP in dit geval, lijkt me. Ik zie niet waarom poorten, protocollen etc mee zouden spelen) over. Hm, als je weet hoeveel entries je hebt, kun je dus kijken hoeveel hosts je kwijt kunt in de cache. Bv 16K , kun je kiezen 1 /18, of 64 /24 netjes, of allerlei combinaties zolang het aantal addressen erin niet meer is dan in de cam passen. Zou dan prima moeten gaan, als je *geen* default route zet..... [knip ]
Nou weet ik niet precies de prijzen, maar heb ik toch sterk het vermoeden dat een office/enterprise omgeving, met een stel servers aan gbit wel behoorlijk goedkoper uit is met L3 switches, dan met een juniper of cisco die de benodigde forwarding performance heeft.
Tuurlijk. Je zult mij ook niet horen/zien ontkennen dat die dozen goedkoper zijn. Dat is dan ook het enige voordeel. En zoals bekend heeft ieder voordeel z'n nadeel.
Yup. Niks wereldschokkends dus al met al, goedkoper, en [dus] soms slechter. Verder was er geloof ik een aspect van onrijpe software, en sales managers die (te) veel beloofden. Ook dat zou niet moeten verbazen, tenminste niet voor de meer ervarenen onder ons .... Boudewijn - maar altijd leuk om over na te denken, en nuttig te weten wanneer je wel en niet weg kunt komen met goedkope(re) oplossingen.
On Mon, 8 Sep 2003, Boudewijn Visser wrote:
Nu ik erover nadenk (en na wat google werk bij de reply aan Jim) eigenlijk wel logisch. Het doen van een longest prefix match lijkt niet zo gebruikelijk/makkelijk te zijn voor CAM geheugen. Dus blijft het cachen van flows (mooi woord voor destination IP in dit geval, lijkt me. Ik zie niet waarom poorten, protocollen etc mee zouden spelen) over.
Poorten en protocollen kunnen wel degelijk een rol spelen bij het bepalen van de next hop/interface. Niet dat dat heel veel gebruikt zal worden, maar ze kunnen het vaak wel.
Hm, als je weet hoeveel entries je hebt, kun je dus kijken hoeveel hosts je kwijt kunt in de cache. Bv 16K , kun je kiezen 1 /18, of 64 /24 netjes, of allerlei combinaties zolang het aantal addressen erin niet meer is dan in de cam passen. Zou dan prima moeten gaan, als je *geen* default route zet.....
Ik geloof dat ik hier je punt ff mis. Of je nu een default route hebt of niet, 16K aan /32's heb je lijkt me nooit genoeg aan.
Yup. Niks wereldschokkends dus al met al, goedkoper, en [dus] soms slechter. Verder was er geloof ik een aspect van onrijpe software, en sales managers die (te) veel beloofden.
Tjek! :)
Ook dat zou niet moeten verbazen, tenminste niet voor de meer ervarenen onder ons ....
En dat kan bovendien nogal wisselen. Zeker de laatste tijd rommelt het nogal in vendor land (qua medewerkers).
- maar altijd leuk om over na te denken, en nuttig te weten wanneer je wel en niet weg kunt komen met goedkope(re) oplossingen.
En hoeveel risico je bereid bent te nemen. De RSS3000's die we hadden deden het op zich prima. Met ons normale traffic patroon. Met het verkeer wat 1 of 2 met slammer geinfecteerde machines genereerden gingen ze beide (redundante setup) onderuit. Dat was het moment dat we besloten de dozen acuut ons netwerk uit de manouvreren. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Mon, 8 Sep 2003, Boudewijn Visser wrote:
Nu ik erover nadenk (en na wat google werk bij de reply aan Jim) eigenlijk wel logisch. Het doen van een longest prefix match lijkt niet zo gebruikelijk/makkelijk te zijn voor CAM geheugen. Dus blijft het cachen van flows (mooi woord voor destination IP in dit geval, lijkt me. Ik zie niet waarom poorten, protocollen etc mee zouden spelen) over.
Poorten en protocollen kunnen wel degelijk een rol spelen bij het bepalen van de next hop/interface. Niet dat dat heel veel gebruikt zal worden, maar ze kunnen het vaak wel.
Ah, inderdaad, als ze ook op basis van port/protocol kunnen routen (tbv van transparante caches, neem ik aan) moet er inderdaad meer dan alleen een destination gecached worden.
Hm, als je weet hoeveel entries je hebt, kun je dus kijken hoeveel hosts je kwijt kunt in de cache. Bv 16K , kun je kiezen 1 /18, of 64 /24 netjes, of allerlei combinaties zolang het aantal addressen erin niet meer is dan in de cam passen. Zou dan prima moeten gaan, als je *geen* default route zet.....
Ik geloof dat ik hier je punt ff mis. Of je nu een default route hebt of niet, 16K aan /32's heb je lijkt me nooit genoeg aan.
Mw, niet helemaal serieus bedoeld, maar gewoon om wat te brainstormen tot welke omstandigheden het ding altijd op maximale snelheid zou moeten kunnen werken. Bv in een kantoor omgeving zonder rechtstreekse internet toegang zou 't handig kunnen zijn om zoiets te weten.
Yup. Niks wereldschokkends dus al met al, goedkoper, en [dus] soms slechter. Verder was er geloof ik een aspect van onrijpe software, en sales managers die (te) veel beloofden.
Tjek! :)
Ook dat zou niet moeten verbazen, tenminste niet voor de meer ervarenen onder ons ....
En dat kan bovendien nogal wisselen. Zeker de laatste tijd rommelt het nogal in vendor land (qua medewerkers).
- maar altijd leuk om over na te denken, en nuttig te weten wanneer je wel en niet weg kunt komen met goedkope(re) oplossingen.
En hoeveel risico je bereid bent te nemen. De RSS3000's die we hadden deden het op zich prima. Met ons normale traffic patroon. Met het verkeer wat 1 of 2 met slammmer geinfecteerde machines genereerden gingen ze beide (redundante setup) onderuit. Dat was het moment dat we besloten de dozen acuut ons netwerk uit de manouvreren.
Yup. Zijn er hier overigens nog riverstone/extreme/foundry experts die wat meer kunnen vertellen over de architectuur van die dozen ? Vaak is zelfs uit white papers, goed zoeken op de vendor site, 'show tech' ed wel redelijk te achterhalen hoe het ding werkt. Of het echt alleen maar 'trust us, we're great' en best-case specs ? Ik heb zelf geen ervaring met die merken, en kan dus alleen maar educated (geen wild :-) ) guesses doen, aan de hand van genoemde symptomen en een stukje achtergrond kennis . Boudewijn
On maandag, sep 8, 2003, at 22:33 Europe/Amsterdam, Boudewijn Visser wrote:
Poorten en protocollen kunnen wel degelijk een rol spelen bij het bepalen van de next hop/interface. Niet dat dat heel veel gebruikt zal worden, maar ze kunnen het vaak wel.
Ah, inderdaad, als ze ook op basis van port/protocol kunnen routen (tbv van transparante caches, neem ik aan) moet er inderdaad meer dan alleen een destination gecached worden.
Of bijvoorbeeld vanwege een access-list; ik kan me voorstellen dat je deze ook bij voorkeur in hardware afgehandeld wil zien.
Mw, niet helemaal serieus bedoeld, maar gewoon om wat te brainstormen tot welke omstandigheden het ding altijd op maximale snelheid zou moeten kunnen werken. Bv in een kantoor omgeving zonder rechtstreekse internet toegang zou 't handig kunnen zijn om zoiets te weten.
Een nuttiger antwoord dan "Afhankelijk van de situatie" is niet te geven, denk ik. Voor kleinere routers (office-omgeving) is performance in het algemeen sterk afhankelijk van de mate van ingewikkeldheid van access-lists, de hoeveelheid active NAT entries (office-omgeving) etc. -- Niels. --
participants (3)
-
alex＠bit.nl -
bvisser-nlnog＠xs4all.nl -
niels.bakker＠ams-ix.net