pinback

hallo allerseits, ich hab folgendes problem : auf unserem tacacs+ server sind u.a. zwei usergruppen definiert : eine gruppe für die remote-einwahl mit authorisierung gegen das AD unserer domäne, eine andere gruppe für den lokalen zugriff auf netzwerkkomponenten mit tacacsü authentifizierung. jetzt das problem : die user der gruppe für den lokalen netzwerkkomponentenzugriff kann sich mit den kennungen in unser vpn einwählen (dafür haben wir aber ja die erste gruppe mit usern). wie kann ich jetzt einem user verbieten, sich von außen einzuwählen ? ist etwas schwierig zu beschreiben das ganze....

das multicast feature behandelt meines wissens nach aber nur ip-pakete, das entscheidende paket kommt aber übers layer2 und ist demnach kein ip-paket. ich lass das mal bei cisco prüfen, wenn was rauskommt, poste ich es. danke für deine hilfe @ daking.

das multicast paket wird an die mac geschickt und kommt auch beim cat an. nur wertet der cat das paket anscheinend nicht aus der cat sieht die mac so : Unicast Entries vlan mac address type protocols port 91 000e.7f3e.a831 dynamic ip Port-channel1 hilft dir das weiter ? ich werd jetzt mal nen call bei cisco aufmachen...

hallo daking ! hm. also ich hab jetzt mal mitgesniffert. sobald der client roamt, schickt er ein multicastpaket raus, das auch beim cisco 2950 ankommt. nur ändert der 2950 seine cam-table nicht entsprechend. er bekommt das paket, ignoriert es aber. hm. ich hab jetzt die timerwerte fürs updaten der table aufs minimum (10sec) gesetzt. aber das ist ja nur ein workaround.

hallo allerseits, folgende situation : - wireless clients + ap's von symbol hängen in einem cisco netz - cisco hardware : 2950er und 6500er problem : sobald ein symbol client den bereich von ap1 verläßt und zum ap2 wechselt, wird die arp information nicht durchgereicht. bisher wurde die arp table alle 4 min refreshed, jetzt habe ich den timer auf 10 sec gesetzt (als quick'n'dirty lösung ok). die frage ist jetzt : warum wird die arp info nicht sofort von den cisco geräten weitergeleitet ? die info müßte vom symbol AP an einen 2950er, von dort über den catalyst an einen weiteren 2950er gehen. aber nix passiert. zumindest nicht sofort, erst beim refreshen der arp table wird die neue MAC übernommen. hat jemand eine idee ?

vielleicht hilft dir das hier weiter : http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/rbkixol.htm#19344 ist die "Cisco IOS Command References Master Index, Release 12.0"

du hast die möglichkeit, zwei actions zu definieren : port storm-control broadcast action shutdown port storm-control broadcast action filter bei shutdown wird der port bei überschreiten des rising-werts administratively down gesetzt. bei filter werden die broadcasts rausgefiltert (glaub ich). wenn die broadcastzahl/sec wieder sinkt, wird bei erreichen des falling-werts wieder die ursprüngliche port-config verwendet -> wie vor dem bc-storm. bei der shutdown-action greift dieser falling-wert logischerweise nicht, weil ja nach dem abschalten keine broadcasts mehr übrs interface reinkommen. die angegebenen werte sind keine prozentwerte, sondern die zahl der tatsächlich empfangenen broadcasts pro sekunde.

das problem hab ich so in den griff bekommen : auf den ports mit einem netgear hintendran folgendes aktivieren : port storm-control broadcast action shutdown port storm-control broadcast threshold rising 4000 falling 1500 der "falling"-wert ist irrelevant, da nach dem shutdown bei erreichen des "rising"-werts der port nicht wieder aktiv geschaltet wird. @utix : die maximale anzahl an broadcasts, die der switch zulässt bevor er die gesetzte "action" ausführt, wird durch den "threshold rising" wert definiert. bei den broadcast-stürmen, die wir hier hatten, sind pro sekunde bis zu 1 mio broadcasts drüber... der wert sollte einfach das ca. 3-fache des normalen broadcast durchsatzes betragen. das haben wir einfach mal so als wert angenommen. wenn ihr das testen wollt, denkt dran, den loop nicht am cisco zu stecken, sondern an einem switch, der an einem port des cisco hängt. sonst funzt es nicht ;)

storm control mußt du auf jedem port aktivieren. wir prüfen momentan die möglichkeit, storm control nur auf den gigabit-uplink-ports zu aktivieren. wir hatten teilweise massive probleme mit dem "shutdown"-parameter. gelegentlich schaltete der switch bei setzen des shutdown-parameters auf einem port einfach alle ports ab wir haben momentan einfach alle ports mit storm control versehen, bei denen einer der besagten netgear-switche hintendran hängt. alles ruhig soweit *klopfaufholz*

ich hatte was wichtiges vergessen... :( vor den cisco 3548 hängen an manchen ports 8-Port Switche von Netgear. Wenn an diesen Switches ein Loop (beide Enden eines Kabels in den Switch) gesteckt wird, entsteht der BC-Storm. In dem Fall greift auch das Spanning-Tree nicht, da die BC's ja über ein einziges Interface reinkommen. sorry für den fehler :(

servus allerseits, wir hatten hier in der firma in letzter zeit mehrere broadcast-storms, die durch als loop gesteckte netzwerkkabel verursacht wurden. im ios gibts ja die möglichkeit, mit hilfe des befehls port storm-control broadcast threshold rising XXXX falling XXXX port storm-control broadcast action shutdown den port am switch bei auftreten eines broadcast-sturms abzuschalten. bei nachstellen der kabel-loop-situation gingen in 10 sek über 9 mio's bc's übers interface. theoretisch sollte bei setzen eines rising thresholds von 5000 der port innerhalb von ein paar sekunden abgeschaltet werden. soweit so gut. vor der firmware 12.0(WC8) funktioniert das allerdings nicht. zumindest nicht zuverlässig. bevor ich jetzt allerdings übers cisco works alle unsere 3548XL's (ca. 20 stück) update, wollte ich mal fragen, ob jemand schon erfahrung mit diesem feature gemacht und welche thresholds ihr genommen habt. danke im voraus :rolleyes: