Jump to content

daking

Board Veteran
  • Content Count

    595
  • Joined

  • Last visited

Community Reputation

10 Neutral

About daking

  • Rank
    Board Veteran
  1. Hi zusammen, nur mal so nebenbei - es gibt nicht mehr ganz aktuelle änderungen des TKG und BDSG - diese wirken sich auf VoIP analysen aus: Analyse von VoIP Sprachverbindungen: TKG § 100 Störungen von Telekommunikationsanlagen und Missbrauch von Telekommunikationsdiensten (1) Soweit erforderlich, darf der Diensteanbieter zum Erkennen, Eingrenzen oder Beseitigen von Störungen oder Fehlern an Telekommunikationsanlagen die Bestandsdaten und Verkehrsdaten der Teilnehmer und Nutzer erheben und verwenden. (2) Zur Durchführung von Umschaltungen sowie zum Erkennen und Eingrenzen von Störungen im Netz ist dem Betreiber der Telekommunikationsanlage oder seinem Beauftragten das Aufschalten auf bestehende Verbindungen erlaubt, soweit dies betrieblich erforderlich ist. Das Aufschalten muss den betroffenen Gesprächsteilnehmern durch ein akustisches Signal angezeigt und ausdrücklich mitgeteilt werden. ==> akustisches Signal oder vorheriger Genehmigung --> Ergebnis: § 201 Verletzung der Vertraulichkeit des Wortes (1) Mit Freiheitsstrafe bis zu drei Jahren oder mit Geldstrafe wird bestraft, wer unbefugt 1. das nicht öffentlich gesprochene Wort eines anderen auf einen Tonträger aufnimmt oder ==> tonträger kann hier ebenfalls eine festplatte sein (oder anderes speichermedium) 2. eine so hergestellte Aufnahme gebraucht oder einem Dritten zugänglich macht. ==> via wireshark abgespielt. also have a nice weekend P.S. natürlich handelt es sich hier nur um Teststellungen die analysiert werden.
  2. Hi, zwischen den VLANs kannst du wie gesagt den IPX Traffic via Fallback Bridging weiterleiten: bridge 1 protocol vlan-bridge ! int vlan 10 ip add x.x.x.x bridge-group 1 ! int vlan 20 ip add x.x.x.x bridge-group 1 ! 6k#sh bridge 1 Total of 300 station blocks, 298 free Codes: P - permanent, S - self Bridge Group 1: Address Action Interface Age RX count TX count ca01.0b58.001c forward Vlan20 0 1 0 ca00.0b58.001c forward Vlan10 0 1 0 ------------- 1#ping ipx Target IPX address: AA.ca01.0b58.001c Repeat count [5]: 1000000000 Datagram size [100]: Timeout in seconds [2]: Verbose [n]: Type escape sequence to abort. Sending 1000000000, 100-byte IPX Novell Echoes to AA.ca01.0b58.001c, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...................... --> Bridge raus ............!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! --> Bridge rein !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!. Success rate is 89 percent (305/340), round-trip min/avg/max = 12/38/-1 ms Das ist also technisch möglich. Aber Vorsicht: der Traffic wird im Software Pfad weitergeleitet. Wenn es sich hier um sehr sehr viel Traffic handelt könnte das eher suboptimal sein. Um wie viele IPX Clients handelt es sich? cheers //
  3. Hi, unter dem Port solltest du noch switchport mode access setzten [ebenfalls switchport nonegotiate] Wie sieht die Config der BG für IPX auf dem 3550 aus? ==> sollte via fallback bridging realisierbar sein. denke ich :-) ciao
  4. Hi, um DHCP mit vrf spezifischen Pools zu aktivieren: ip dhcp use vrf connected Zum Weiterleiten der via IPCP empfangenen DNS Server Adresse (die wird in der vrf empfangen und nicht in der globalen Routinginstanz - siehe oben) sollte die Config passen. ciao
  5. Hi, ja der Signalling Traffic muss ebenfalls transparent durchgereicht werden - also mit dem definierten Wert für die SIG Klasse ankommen. Es gibt zwar Modelle in denen dies nicht passiert - sprich die Markierung im Backbone geändert werden kann - ist aber hier denke ich nicht im Einsatz. Scheint eine fehlerhafte Klassifizierung zu sein. Ihr habt eine COS1 Klasse (interessantes naming) für VoIP geordert - Dies mit 384 kbit/s - Woher kommt diese Berechnung? Wird hier ebenfalls der Signalling Traffic transportiert oder soll der in der default Klasse laufen? Na ja erst mal das Marking hinkriegen - 128M interessant - eigentlich reicht hier doch ein einfacher Call. Ja mit MPLS habe ich schon mal was gemacht :-). cheers
  6. Hi, sind beide ports gleich konfiguriert? wenn nein auf der monitor dest ebenfalls dot1q aktivieren. ebenfalls mal testen mit monitor session 1 destination interface gigabitEthernet <ifid> encapsulation replicate versuchen. Mit Boardmitteln kannst du ebenfalls testen falls mls qos aktiviert ist --> sh mls qos int <foo> statistics. Ihr habt eine 802.1q Verbindung zum Provider? Ebenfalls sollte der Provider sehr schnell sagen können, ob er matches in der RT Klasse hat.. hope this helps cheers
  7. Hi, ok - die Frage ist nun wo die MAC gelernt wird oder ob diese gelernt wurde. Also für die gefluteten mac addr mal sh mac-addr <x.x.x.x> vlan x. Auf der SUP2 sollte es ebenfalls sh mac-add unicast-flo geben, dann sollte im log jedoch ebenfalls eine meldung ausgegeben werden. Ist dies ein permanentes flooding oder tritt es in intervallen auf? Mehr Info über das Setup macht immer Sinn - also kurze skizze. ciao
  8. Hi Otaku, welche tec session haste am Mo gebucht? bei wird wohl nun leider auch nichts.. ciao
  9. Hi, komisches Capture File. Mit welchem Tool haste das File erzeugt und mit welchen Einstellungen. CapLen begrenzt? (und auf dem testlaptop facebook offen - :-)) Wenn du diesen Traffic an jeden Port siehst - ist das def nicht ok. Nun zur Analyse - welche Module/SUP sind im Einsatz (DFC/CFC) - welche Aufgaben hat hier der 6k? (rein l2/l3 - services) - was sagt sh spann det für dieses vlan (werden hier die tc hochgezählt) - was sagt sh mac-address detail|all für die gefluteten mac adressen? - was sagt sh mac-address count ? - was sagt sh vlan virt slot x (alle slots) @Otaku: hier wird max 10kbit/s und max 10pps generiert. Sollte kein Problem sein. ciao
  10. Hi, switchport oder routed port sollte da recht egal sein. Mit den ip flow kommandos können pakete die zur MSFC weitergeleitet via netflow ausgewertet werden. Wenn du Pakete die durch die HW (PFC) weitergeleitet werden analysieren willst, wird dies via mls kommandos realisiert. Das sollte helfen: https://supportforums.cisco.com/thread/1003948 --> per interface netflow wird erst ab Withney-1 (SXH) unterstützt btw - egress netflow wird nicht unterstützt ciao
  11. Hi, mit dieser config kannst du netflow auf dem rp aktivieren - also nicht auf dem hw fwd. solltest da eher mal in der ecke mls nde und mls netflow suchen. ciao
  12. Hallo, // Unfortunately, egress NetFlow is not supported in hardware on any PFC3* system \\ im default werden auf dem 65er alle ingress HW Flows accounted. Egress ist auf EARL7 in HW nicht supported (kommt mit EARL8). Mit mls nde können die HW Switched Flows exportiert werden. ip flow Kommandos accounten nur punt-to-cpu traffic, sprich software switched flows. Für egress netflow sollte es eine Ausnahme geben - egress multicast accounting. Die Suche in den Release Notes wird vergeblich sein ;-(. Falls du eine Herstelleraussage willst --> Case bei Cisco --> Viel Spass ciao
  13. Hi, egress netflow wird nicht in unterstützt. ciao
  14. Hola Otaku, die constellation+ platform lebt :-) - wird wohl noch ein wenig dauern, bis wir hier die schwarzen anzüge anziehen müssen und alle auf junos logik migrieren (aka XR) - aber "set xx" ist schon irgendwie kätzerei! :-) p.s. I'm allready migrated p.p.s: http://blog.ine.com/wp-content/uploads/2010/04/understanding-stp-rstp-convergence.pdf ==> input
×
×
  • Create New...