Jump to content

daking

Members
  • Content Count

    595
  • Joined

  • Last visited

Everything posted by 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
  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
  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
  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
  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
  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-poli
  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 Üb
  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
  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-ta
  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. 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
×
×
  • Create New...