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