Jump to content

daking

Members
  • Gesamte Inhalte

    595
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von daking

  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. daking

    Netflow Config

    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. daking

    Netflow Config

    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. daking

    mls netflow

    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. daking

    mls netflow

    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
  15. Hi, ja mit 80 für IP und 100 für ETH bist du für ein Gespräch falls g.711 auf dem richtigen Weg. Bei ADSL würde ich da noch auf 120 gehen (Cell Padding und Co.). Zur Markierung der RTP Packete könntest du Eingangsseitig folgende policy verwenden: ip access ext AVM_RTP permit udp host <AVM IP> range 10000 11000 any (vielleicht auch range wie vorher) ! class-map RTP match ip address AVM_RTP [vielleicht klappt auch match protocol rtp - braucht jedoch mehr ress] ! policy-map MARK class RTP set ip dscp ef ! int x/y desc da ist die Box service-policy in MARK ! ciao
  16. Hi, also dann wieder das übliche - Du musst am Cisco die Überlast erkennen, d.h. du musst den Flaschenhals von 2mbit/s dort am Ausgangsport simulieren. Das Bandwidth kommando ist nur ein hilfsmittel für routingprotokolle und für prozentuale Bandbreitenangaben in policy-maps. Hierfür kannst du nested policies verwenden: ! policy-map Q class VoIP priority percent xx | priority <rate> class class-default fair-queue ! policy-map 2M class class-default shape average 1900000 service-policy Q ! Die policy-map 2M shaped auf 2M (mit def 25ms TC) bei Überlast regelt Q das Queueing - VoIP bekommt eine bestimmte Bandbreite mit LLQ Eigenschaften. Beachten solltest du, dass du keine 2048 mbit/s Nutzbandbreite hast und wieviel du für RTP/VoIP Calls reservieren willst - Ebenfalls solltest du nicht nach der BOX IP matchen sondern die RTP Pakete mit einem DSCP Wert versehen - das sollte die AVM Fritzbox können. Hope this helps ciao
  17. Hi, die IP SLA Messung an sich funktioniert ja - Es wurde halt Packet Loss festgestellt. Die Messung geht auf != OK wenn der Responder nicht erreichbar ist oder sonstige Fehler auftreten. Die reaction-configuration Funktion sollte mit dieser Config funktionieren - du siehts im Moment nur nichts - Also: -- ip sla logging traps -- und sicherstellen, dass der action-type auf traponly steht: -- ip sla reaction-configuration 3 react packetLoss threshold-value 2 1 threshold-type immediate action-type trapOnly -- Dann sollte nun im Log für auftretenden Packetloss folgende Meldung kommen '1248: 000823: Jun 35 13:11:24.600: %RTT-4-<Packetlos..>: condition occurred, Bei der nächsten Messung die ohne PKT Loss ist: '1248: 000823: Jun 35 13:11:28.600: %RTT-4-<Packetlos..>: condition cleared. Diesen Trap kannst du extern auswerten und dann via snmp die letzte Messung abfragen --> Prozent bestimmen --> Aktion definieren. Oder lokal auf dem Router via EEM hope this helps cheers
  18. das sollte mit einem mix aus NAT,static route-leaking und BGP funzen (dann kann man das auch auf weiter Kunden erweitern) - das inter vrf routing ist mit gleichen p2p interface adressen ein wenig strange - das sollte man nochmal überdenken. Hier die Config des Core Routers (warum sind da keine Routernamen in der Grafik - ok next time). Also der Router in der Mitte. ---snip ip vrf vrf11 rd 1:1 export map TAG route-target export 1:1 route-target import 1:1 route-target import 99:99 !e-comm für inter-vrf ! ip vrf vrf12 rd 2:2 export map TAG route-target export 2:2 route-target import 2:2 route-target import 99:99 !e-comm für inter-vrf ! router bgp 64000 no bgp default ipv4-unicast bgp log-neighbor-changes ! address-family ipv4 vrf vrf11 no synchronization redistribute ospf 1000 vrf A metric 100 route-map INTER_VRF !IGP oder was immer in der VRF exit-address-family ! address-family ipv4 vrf vrf12 no synchronization redistribute ospf 2000 vrf B metric 100 route-map INTER_VRF !IGP oder was immer in der VRF exit-address-family ! ip nat pool VRF_A 9.9.1.0 9.9.1.254 netmask 255.255.255.0 !was auch immer Richtung Global ip nat pool VRF_B 9.9.2.0 9.9.2.254 netmask 255.255.255.0 !was auch immer Richtung Global ip nat inside source route-map NAT pool VRF_A vrf vrf11 ip nat inside source route-map NAT pool VRF_B vrf vrf12 ! ip route vrf A 10.88.0.0 255.255.0.0 <OIF_to_FW> <FW> global ip route vrf B 10.88.0.0 255.255.0.0 <OIF_to_FE> <FW> global ! ip access-list standard LEAK permit 192.168.1.0 0.0.0.255 permit 192.168.2.0 0.0.0.255 ! ip access-list extended NAT-PERMIT permit ip 192.168.0.0 0.0.255.255 10.88.0.0 0.0.255.255 ! route-map TAG permit 10 match ip address LEAK set extcommunity rt 99:99 additive !ADD RT for INTRAVRF ! route-map INTER_VRF permit 10 match ip address LEAK ! ! route-map NAT permit 10 match ip address NAT-PERMIT ==> Routen auf der FW und CO Richtung Nat Bereich nicht vergessen C1_A#ping 192.168.2.1 source loopback 0 repeat 1000 Type escape sequence to abort. Sending 1000, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds: Packet sent with a source address of 192.168.1.1 !!!!!!!!!! Success rate is 100 percent (10/10), round-trip min/avg/max = 244/369/492 ms ! C1_A#ping 10.88.2.1 source loopback 0 repeat 1000 Type escape sequence to abort. Sending 1000, 100-byte ICMP Echos to 10.88.2.1, timeout is 2 seconds: Packet sent with a source address of 192.168.1.1 !!!!!. Success rate is 83 percent (5/6), round-trip min/avg/max = 268/318/408 ms ! C2_A#ping 10.88.2.1 source lo0 repeat 1000 Type escape sequence to abort. Sending 1000, 100-byte ICMP Echos to 10.88.2.1, timeout is 2 seconds: Packet sent with a source address of 192.168.2.1 !!!!. Success rate is 80 percent (4/5), round-trip min/avg/max = 272/341/416 ms ! CORE#sh ip route vrf A | beg last Gateway of last resort is not set 1.0.0.0/32 is subnetted, 1 subnets O 1.1.1.1 [110/2] via 10.5.5.1, 01:12:30, FastEthernet1/1 10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks O 10.1.1.0/30 [110/2] via 10.5.5.1, 01:12:30, FastEthernet1/1 C 10.5.5.0/30 is directly connected, FastEthernet1/1 L 10.5.5.2/32 is directly connected, FastEthernet1/1 S 10.88.0.0/16 [1/0] via 192.168.254.1, FastEthernet2/0 192.168.1.0/32 is subnetted, 1 subnets O 192.168.1.1 [110/3] via 10.5.5.1, 01:12:30, FastEthernet1/1 192.168.2.0/32 is subnetted, 1 subnets B 192.168.2.1 [20/100] via 10.5.5.1 (vrf12), 01:12:14, FastEthernet1/0 CORE# ==>5.5.5.1 (interessant) ==> hoffe ich habe nichts vergessen.. na ja mal sehen hope this helps ciao
  19. Hi, Routing zwischen VRF's ist nicht das Problem - die Frage ist was du genau machen willst? Haben die beiden Routinginstanzen die gleichen IP Ranges im Tranferbereich oder generell (wirklich?). Warum willst du in die globale RT routen? cheers
  20. Hi, das solltest du auch mit sh mls qos int x/y statistics sehen. ciao
  21. daking

    sh terminal

    Hi, unter der line: line con [vty] x [y] trans pref ssh ! dann wird falls unter router>#1.1.1.1 eingegeben wird ssh 1.1.1.1 ausgeführt. mit trans pref none ist es möglich dieses verhalten zu deaktivieren. dann muss man ssh -l ... 1.1.1.1 angeben und (1.1.1.1 geht nicht mehr).. hope this helps ciao
  22. Hi, na ja - für features, die man nicht benötigt muss man halt zahlen - wer weiß ob diese features nicht doch mal benötigt werden - dann ist man wenigstens auf der sicheren seite :-) [consulting modus on - nicht "ganz" ernst nehmen..] cheers
  23. Hi ShineDaStar, sollte hier nicht eher ein SVI als MGMT Interface (oder Loopback :-)) definiert sein? Management wirst du ja über das LAN machen wollen, oder? cheers
  24. Natürlich macht ein Loopback Interface auch sinn. Man benötigt jedoch eine weitere IP Adresse die ggf im Distri Bereich geroutet werden muss. no autostate würde das gleiche Ergebnis bringen.. cheers
×
×
  • Neu erstellen...