[Nlnog] Cisco?

[Alex Bik]

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