[Nlnog] Cisco?

[Boudewijn Visser]

> 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