Otaku19

na steht ja grob eh schon da ;) Hätte vielleicht schreiben sollen das ich mit Provider Mobilfunkbetreiber meinte

a hört sich jetzt mal nach provider an, sprich das wäre so ind 5580 Gegend. Mit GTP werden die "Funkdaten" via IP transportiert. b hört sich nach NAC/802.qX blabla an

QoS zu konfigurieren ist ohne Hintergrundwissen über QoS Mechanismen an sich und Kenntnis über das Trafficverhalten unmöglich. Wenn man das erste Mal damit zu tun hat wird man nichts brauchbares zu Stande bringen, ausser es geht um sehr einfach Dinge

stimmt :) dann muss man sich natürlich das Paket etwas genauer ansehen :)

wenn du schon mit Cisco arbeitest und du grundlegendes Wissen hast ist ein Kurs rausgeschmissenes Geld, hol dir lieber mal ein, zwei Bücher und evtl zum abprüfen nen Testking oder so. Das kommt weit billiger als ein Kurs.

Und wo sind wir hier ? Ebend, musst schon sagen das es auch um nicht Ciscogeräte geht ;) Nachteil vom Monitorport ist halt das dem evtl dei Puste ausgeht, je nachdem wie viel Traffic da mitprotokolliert werden soll. Wennd a auch interne Kommunikation mitrein soll wird ein SPAN vermutlich nicht reichen..und rein für die Auswertung brauchts nicht die kompletten Frames. Dummerweise ist afaik auf Cisco Netflow irgendwie "gemittelt", sprich da wird nciht wirklich jedes einzelne Paket erfasst. Aber das machts kraut auch nicht fett, für eine Überblick reichts allemal. SPAN würde ich wirklich nur dann machen wenn ich einen Sniffer dranhabe um mir nachher einzelne Frames anzuschauen. Und da eben auch, je nach trafficvolumen muss da auch mal eine potente Maschine dran oder gar ne Sniffer Appliance.

Verwechsel den Kurs nicht mit der Zertifizierung...

gibt auch viele die QoS in ihrem ausgedehnten LAN am laufen haben.

das hat mit syslog nichts zu tun, was du brauchst ist IP Accounting/Netflow. Da lässt sich das "bequem" auswerten

im SDm kannst du einiges konfigurieren was im CCNA Kurs nicht abgedeckt wird :) CCNA hat ja imho noch immer IP Unwissende als Zielpublikum, denke mit Subnetting, Routingprotokollen und Switchingbasic ist man da eh schon beschäftigt genug, da brauchts kein QoS mehr um die leute noch mehr zu verwirren. Ich weiß bei QoS nur grundbegriffe, wozu es gut ist und wo man ungefähr zu schauen hat wenn mans konfiguriert, das wars dann auch schon wieder. Ich hab mir da zum Glück noch nie irgendwelche Settings zusammenreimen müssen

das kommt darauf an :) ich sage mal wenn es wirklich zu 100% sicher ist das die VLANS nie untereinander (also jetzt die neuen mit den alten) kommunzieren und auch keine Dienste nach draussen anbieten, dann köntne man schon mit einer ACL leben. Ab dem Moment wo da irgendwelche Server drin sind die von draussen erreichbar sind oder Zugriffen zwischen den VLAN notwendig sind ist eine Firewall schon besser bzw ist es fahrlässig keine FW davor zu haben. Vor allem weiß ich nicht wie ein 3750 die ACL handlet, wenn das CPU lastig ist sollte man das filtern nicht unbedingt auf seiner zentralen Routinginstanz haben. ich hab jetz absichtlich nicht ASA geschrieben, die Firewallentscheidung hängt von zig Punkten ab

anscheinend kein oder ein defektes Image drauf laut: IOS Software Installation and Upgrade Procedure Aber vorm draufspielen ist ein formatieren natürlich keine schlechte Idee..vor allem denk ich mir, selbst wenn das IOS da hinüber(nicht vorhanden wäre...warum sollte man sich nicht andere Files am Flash anschauen können ?

beim CCIP gibts zB eine QoS Prüfung, bei CCNP wäre es ONT in diese Richtung. QoS ist definitv kein Thema bei CCNA

höh ? Aus welchem Jahrzehnt stammt das ?

einlesen: Configuring Context-Based Access Control [Cisco IOS Software Releases 12.2 Mainline] - Cisco Systems zonebased wäre hier ein brauchbarer Ansatz: Zone-Based Policy Firewall Design and Application Guide - Cisco Systems Ansonstne, ein Router ist nun mal keine Firewall, warum wurde nicht gleich ne ASA angeschafft ?

zeig mal die konfig

wenn er das so umsetzen würde, dann wären wohl aufwändige Umadressierungen notwendig. Und damit wohl auch etliche Freischaltungen. Evtl ne Art "segmentierte" DMZ, so kann man zwar eien Maschine kompromitieren, von da aus aber keien weitere in diesem Segment.

ich glaube fast, das geht überhaupt nicht in so einem Szenario, da müssten policies ala enterasys direkt am interface sitzen und alles müsste direkt am access-switch geregelt werden

damit kann jeder ganz leicht den DHCP Server DoSen oder selber DHCP spielen. Von daher wäre DHCP Snooping nicht verkehrt

das kann auf diesem Weg nicht anders ehen weil der Client nun mal noch keien Source IP besitzt. Andere Lösungen wären dann zB via 802.1X und dessen Gast VLAN. Was so und so (also 802.1X allgemein) eien gute Idee ist

Falsch, es verhindert Layer 2 Loops :)

denke nciht das das die Firewall übernehmen kann

es gibt kein Standard VPN. Poste die wichtigen Teile (natürlich ohne irgendwelche Passwörter oder echter offiziöser Adressen) einfach hier

diese Portforwards konfiguriert man mit statischen NATs, per default kann man sowieso von jedem Interface aus auf den Router, das müsste man per ACL (access-class am vty) einschränken. Hier wäre gleich SSH zu empfehlen. Welches VPN willst du denn nutzen ? Ich nehme an einfaches IPSEC Remote Access mittels Client am Laptop und der Router soll der Endpunktsein ?

glaube Bridgen geht nur mit switching interfaces, das wird hier nicht funktionieren. Aber die Idee das via Routing umzubiegen wäre natürlich ne feine Sache, der Ausfall wäre vielleicht ein wenig länger als ein HSRP Switch, aber auch der hakt hi und da mal. Die Switche benötigen ja auch keien grossen Tables, die bekommen eien default route und gut ist