Jump to content

daking

Members
  • Gesamte Inhalte

    595
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von daking

  1. daking

    Mpls Vpn

    Hallo, ich bin auf dem Schlauch gestanden... so gehts natürlich.... (;-) ip vrf kunde1 rd 8500:101 route-target export 8500:101 route-target import 8500:101 route-target import 8500:100 ! ip vrf kunde2 rd 8500:102 route-target export 8500:102 route-target import 8500:102 route-target import 8500:100 ! ip vrf zentrale rd 8500:100 route-target export 8500:100 route-target import 8500:100 route-target import 8500:101 route-target import 8500:102 ciao
  2. daking

    Mpls Vpn

    Hola, am einfachsten kannst du IMHO ein Hub and Spoke Design im grossen Stil über Half Duplex VRFs lösen. Da war denke ich nur das Problem, dass dies nur über virtual templates funktioniert...Habe es selber auch noch nicht getestet (steht auf der liste...time...). Sonst solltest du unter der vrf über den import map filtern können oder über den bgp prozess.. Da muss ich nochmal schnell schauen... – Hola, na ja. vielleicht gehts einfacher so ?! mal sehen: ip extcommunity-list 1 permit rt 100:1 route-map test permit 10 match extcommunity 1 address family vpnv4 neighbor x.x.x.x activate neighbor x.x.x.x send-community extended neighbor x.x.x.x route-map test out Werde das kurz mal testen.. Eigentlich sollten man über die ext communities ja filtern können... Kann jedoch sein, dass ich mich brutal irre.
  3. daking

    Cisco VSS

    Hallo, die BFD neighbours sollten sich sehen, wenn der VSL Down ist (das ist der Trigger). Folgende Vorraussetzungen werden benötigt -->An ip address must be configured on the interface. !!-->The two interfaces must be on a different subnet. -->Bfd interval parameters must be configured on the interfaces. -->The bfd dual-active detection mechanism must be enabled – this is configured using the “dual-active detection bfd” command. -->The pair of interfaces to be used in the detection mechanism must be specified using the “dual-active pair interface” command. But: Action upon Dual-Active Detection: ------------------------------------ !! Upon detecting the dual-active condition, the original !!active chassis !! enters into recovery mode and brings down all of its interfaces except the VSL and nominated management interfaces, effectively removing the device from the network. To nominate specific interfaces to be excluded from being brought down during dual-active detection recovery, use the following commands: vss(config)#switch virtual domain 10 vss(config-vs-domain)#dual-active exclude interface gigabitEthernet 1/5/3 WARNING: This interface should only be used for access to the switch when in dual-active recovery mode and should not be configured for any other purpose vss(config-vs-domain)#dual-active exclude interface gigabitEthernet 2/5/3 WARNING: This interface should only be used for access to the switch when in dual-active recovery mode and should not be configured for any other purpose vss(config-vs-domain)# ==> Doch das active chassis (;-(.. module down... ==> Nach dem stecken des links sollte der nun standby reloaden ( vorher active).. ==> nach dem rebooten wird der switch nun in prefered standby starten.. ==> nicht die BFD Interfaces excluden ==> die sind schon excluded.. ==> da hab ich falsch gedacht .. Hope this helps (;-)
  4. daking

    Cisco VSS

    Hola, Hat bei uns geklappt.wie sieht deine Config aus? Switch IDs richtig gesetzt? was sagt sh switch virt link? sh switch virt red? sh switch virt role? brgds TS – Hallo, //Trotz preemt muss ich die Zuordnung per reload mit beiden wiederherstellen.// das verstehe ich nicht?! Du musst nach dem reboot die Zuordnung von Switch_A =1 und Switch_B = 2 neu definieren. Beim Boot sollte dies durch die Variable: Sys_A#switch set switch_num [1 | 2] Set rommon's switch_num to 1 Sys_A#switch read switch_num Read switch_num from rommon is 1 definiert werden. Eigentlich sollten die vars beim convertieren automatisch gesetzt werden. Nur beim Tausch der Sup muss man diese neu setzten. Was gibt bei die switch read .. aus? brgds TS
  5. stell mal das eth interface zum DSL Modem auf auto/auto ==> wie steht das interface dann FDX / HDX?
  6. Hola, siehst du mit sh ip traffic fragmented packets?! ==> unter dem dialer noch ip tcp adjust-mass (mtu - 40 Byte) ==> 1452 eingeben und testen. ciao – stell das inteface zum dsl modem mal auf auto/auto ==> wie steht das interface dann FDX/HDX?
  7. Hallo, denke das zwei Router + GLBP (falls diese die Routinginstanz für die Clients) oder drei Router im Dreieck + zwei Def Routen das einfachste sind. brgds
  8. daking

    Cisco VSS

    Hallo, falls der VSL Link down geht [sOLLTE] Dual Active Detection greifen und der Standby Switch alle LCs down nehmen (ausser den Link für Dual Active). Das hat teilweise noch eher suboptimal mit einer ganzen Latte an Tracebacks funktioniert... Sonst ist VSS definitiv hot und die Konvergenzzeiten sind natürlich sehr gut. Wenn nun noch Service Module und MPLS unterstützt werden ist die Sache ready (Withney 2). VSS könnte man als Stacking Variante bezeichnen. Eigentlich wird ein Fabric Channel über den VSL erweitert wie der Stacking Link beim C3750. Hier wurde auch diesmal gleich an sinnvolle Kommunikation gedacht (nicht wie bei der non E Serie des C3750 wo Port zu Port Kommunikation auf dem gleichen Switch gut mal über alle Stackmember gehen kann (;-() ==> Der VSL Link sollte für Datentraffic "fast" nicht benutzt werden. Eine redundante Auslegung des VSL ist auch nur für redundanzzwecke gedacht, d.h. über den zweiten Link des Po wird kein Traffic laufen.. Kein portchannel loadbalance.. Bin mal gespannt wie die erste Withney 2 mit Servicemodulen läuft. Das wird denke ich ein spass.....
  9. Hola, anderer Router mit zwei interfaces oder zwei Router + PFR. BGP wird für PFR nicht benötigt. http://www.cisco.com/application/pdf/en/us/guest/netsol/ns483/c649/ccmigration_09186a008094e673.pdf
  10. Hallo, @Thimax: // Ich perönlich war ja immer der Meinung, dass Router sich in einem Ethernet Netzwerk der Situation anpassen. Was soviel heisst dass sie nur dann anfagnen zu routen, wenn die Destination-IP Adresse sich in einem anderen Subnetz befindet. // ==> klar der Router wird die Kommunikation innerhalb eines Subnetzes im normalfall nicht mitbekommen, da die Clients ihn nicht adressieren. // Insbesondere dient ja IP CEF dazu, dem Router zu sagen die Packete zu switchen (ein Vorgang der weniger Leistung braucht als das Routen) // ==> benötigt weniger leistung, da weniger lookups.
  11. Hallo, an sich kommunizieren router auch auf layer 3. router kümmern sich um ip prefixe und machen nach deren eine forwarding entscheidung. Welche l2 technick drunter liegt ist dann nebensache. Beim generieren des Pakets am ausgehenden interface muss halt in den ethernet header eine ziel mac stehen um dem vielleicht dazwischen geschaltenen switch die l2 switching entscheidung zu erleichtern.. hope this helps.
  12. Hallo, hier vielleicht ein wenig Cisco lastiger (ausgegangen von aktiviertem CEF Switching) 1. PC sendet packet an router ==> source mac PC ==> dest mac Router (das hat der pc dann aus dem arp cache ==> arp -a) 2. am incoming interface der Routers wird das Paket empfangen und die Art des Forwarding definiert: a. Prozess Switching b. Flow Switching c. CEF Switching Dies ist abhängig von den aktivierten Features. generell ist die Frage, ob der RP oder die CPU aus bestimmten Gründen das Paket sehen muss. Gründe für eine Fallback auf den nächsten (schlechteren) Forwarding Path sind z.B. gesetzte IP Optionen, Suboptimale TTL Werte (manchmal natürlich auch sinnvoll) oder auch Features, die im optimalen Switchingpfad nicht unterstützt werden. Gehen wir nun vom optimalen CEF Pfad aus.. Was ist vorher passiert: - Der Router hat routen gelernt (dynamisch, statisch oder connected) - Der Router hat Mac Adressen gelernt (via ARP ==> im Arp Table) --> nun wird der Routingprozess nach administrativer Distance, Metric usw. bestimmte Routen in der Routing Information Base installieren. Die besten natürlich. Der CEF Prozess wird nun versuchen für die gelernten Ip Prefixe 1. Die IP Prefixe in einem Binary Tree aufzuteilen 2. den next hop im arp table zu finden 3. das ausgehende interface zu definieren aus 1. wir nun die Forwarding information Base (FIB) aus 2. + 3. wird nun der Adjacency Table FIB und Adjency Table werden nun verknüpft. Für jedes Prefix wird es nun ein outgoing interface und eine rewrite action geben Hätten wir nun ein TCAM basierendes System (like 6k) wird die FIB Information + Adjacency Table noch ein wenig komprimiert und in diesem für schnelle und parallele Lookups optimierter Speicher abgelegt. ==> Forwarding in HW ==> Nun wir das Ip Prefix (Destination IP) im FIB (TCAM) analysiert. Falls ein Outgoing Interface und eine L2 rewrite action vorhanden sind. Wir der L2 Header am OUTGOING Interface umgeschrieben (MAC vom Nexthop aus dem Adjacencytable) ==> Falls nun eine andere technik im Einsatz ist FR / ATM / MPLS. wird halt dann ein andere rewrite action gewählt (ein header - mehere). ==> Wenn wir über ethernet sprechen MUSS die MAC Adresse des Next Hops sinnvollerweise bekannt sein. Sonst würde der Router/Switch am outgoing interface die Pakete flooden (like Unicast Flooding). hope this helps.
  13. Hallo, - Eine von mehreren redundanten Links vom Access-Switch zum Core geht down. Mit Ping lässt sich das nicht überwachen ==> via syslog + LMS (Cisco Works) [ logging event link-status logging event trunk-status logging event bundle-status] - Fehler auf Interfaces (CRC, Drops, Input&Output Error, usw.) live anzeigen, evtl. über Nagios überwachbar. Unbedingt Live-Überwachung ==> via rmon + snmp trap + cisco works für monitoring ==> lms ist nicht mein spezialgebiet aber denke das sollte gehen. - Live-Monitoring Syslog der Geräte auf kritische Meldungen, z.B. Lüfter ausgefallen) ==> cisco works - Überwachung Performance-Engpässe auf allen Punkten im Netzwerk (CAT6500, Access-Switches, FWSM, ASA, versch. Router) ==> via ip sla + cisco works Und kennt ihr Firmen, die so eine Überwachung profesionell aufsetzen würden? ==> no problem! ciao TS ==> muss auch nicht unbedingt cisco works sein.
  14. daking

    Cisco VSS

    Hallo, war Anfang des Jahres in San Jose zum VSS testen. Funktioniert soweit ganz gut. Wichtig ist hier, dass du nur 67 Karten und eine 3C PFC / DFC benötigst. Im Moment benötigts du einen dedizierten Link für Dual Active Detection. Service Module wie FWSM usw. werden ab Withney 2 unterstützt (mal sehen..). Pass auf wenn du den VSL Link konfigurierst ==> die portchannel ID ist nur ohne VSS local significant. Mit VSS ist es ungut, wenn du auf beiden Seiten po1 konfigurierst. Es gibt auch die Möglichkeit Switche [ohne] Ausfall auf VSS zu migrieren.. Für die Dual active detection kannst du entweder PAGP+ oder BFD verwenden. Ich würde da eher BFD priorisieren.... Cisco Catalyst 6500 Series Virtual Switching System (VSS) 1440 [Cisco Catalyst 6500 Virtual Switching System 1440] - Cisco Systems Virtual Switching System (VSS) Q&A [Cisco Catalyst 6500 Virtual Switching System 1440] - Cisco Systems http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps9336/white_paper_ciscos_virtual_switch_smashes_throughput_records.pdf brgds TS
  15. Hallo, was hat nun QOS mit [L3] Loadbalancing zu tun? Aus QOS sicht gibt es phy oder virt interface mit einer bestimmten Bandbreite. Falls du mehrere Subscriber via PPPOE oder vielleicht L2TP terminiren willst und dort an dieser Stelle (BRAS) QOS in Richtung Kunde realisieren willst geht es hauptsächlich um die Deklaration der Richtigen Hardware für diesen Zweck. Ich kenne leider deine Konstellation nicht genau. Im Normalfall (mehrere Kunde via PPPOE / L2TP) sollte hier H-QOS (im Cisco Syntax) oder Subsciber Based QOS (Juniper) interessant sein. Hier handelt es sich hauptsächlich um Provider HW. Welche HW benutzt ihr als LNS. Die Grenzen ältere HW sind eng geschnürt.. QOS in HW und nicht anderen Pfaden ist teilweise also nicht möglich.. ciao
  16. Hola, das kann ich dir nicht sagen, da es mir noch nie passiert ist.. ==> Generell sollte bei Start Fragen Cisco Systems, Inc befragt werden ==> eine Suche nach config-register sollte hier hilfreich sein. ==> Falls man die IOS SW Updated ==> sollte man vor reboot das register überprüfen ==> die meisten Fehler passieren auf Layer 8. Jeder Step sollte überprüft werden. brgds //
  17. daking

    876 Router

    Hola, wie siehts nun aus? zwei calls sollten hier mit schlechter TCP Performance klappen. Die Frage ist nur was man plant und designt. Im optimalen Fall sollte der RT Traffic "nicht" den Datenverkehr "beeinflussen". 3M zu 500Kbit/s ist eher die Notlösung.. brgds //
  18. Hola, #sh ver | inc Con Configuration register is 0x2102 (0x2101) # ==> falls nicht 2102 oder 2101 ==> conf t ==> config-register 0x2102 ==> wr ==> reload (oder auch test crash) ==> should work bye
  19. daking

    876 Router

    Hola, welchen Codec verwendest du (G.711 / G.729 / G.723) --> Coderintervall?(20ms / 30ms) welche Upload Bandbreite hast du? test#sh dsl int atM 0 | inc Speed Speed (kbps): 3456 0 448 0 test# ==> 3456 kbit/s down / 448 kbit/s up ==> 448 ist hier interessant Hier die Kalkulation der benötigten Bandbreite pro Call (Beispiel G.711a - 20ms) Overhead: [iP Overhead] Voice Payload ==> 160 Byte RTP Header ==> 12 Byte UDP Header ==> 8 Byte IP Header ==> 20 Byte Ethernet Header ==> 14 Byte [iPSEC] falls vorhanden tunnel / transport tunnel IP Header ==> 20 Byte ESP IV ==> 8 Byte ESP Header ==> 8 Byte ESP PAD ESP Auth ==> 12 Byte IPSEC Header ==> 20 Byte [ATM / PPPOE] PPPOE Header ==> 8 Byte AAL5 Header ==> 10 Byte AAL5 Trailer ==> 8 Byte = 308 Byte Packet Size ==> wie viel ATM Zellen? ==> 308 / 48 Byte = 6,41 ==> let's pad ==> 7 ==> 7 Zellen pro VoIP Paket ==> 7 * 53 ( 53 Byte Zellen mit overhead) ==> 371 Byte ==> Nun 20 ms Coderinterval ==> 50 pps ==> (371 *8) * 50 pps / 1000 ==> 148,4 kbit/s Mit 448 kbit/s sollte das kein Problem sein. Das Problem könnte unter Last das Delay sein (kleiner 784kbit/s Delay issue) ==> tune mss ==> tune per vc tx-ring (minimal 3) ==> check service-policy LLQ Bandbreite und Drops ! int atm0 pvc x/y tx-ring-limit 3 ! ! interf dialer 100 ip tcp adjust-mss 592 ! ==> die class-maps solltest du natürlich ebenfalls anpassen (match-all) ciao – Hola, falls du ingress Klassifizieren willst class-map match-all RTP match protocol rtp ! class-map match-all Skinny match protocol skinny ! policy-map MARK class RTP set dscp ef clas Skinny set dscp af31 ! interface vlan xxx service-policy in MARK ! ==> die CCM Config muss RTP und Skinny markieren... ciao
  20. daking

    876 Router

    Hallo, die VoIP Klasse sollte denke ich erst mal match-all sein ==> also DSCP 46 UND die ACL und nicht match-any DSCP 46 ODER die ACL. In der Klasse VoiP matched die ACL aber nicht die DSCP 46 regel ==> dscp 46 ist eine zeile höher als die ACL ==> d.h. falls die IPPs dscp 46 senden würden solte es umgedreht sein. ==> IP Phones checken ==> Switches checken (mls qos trust ...) Für VoIP mit Cisco ist es sehr wichtig den Skinny Traffic in einer eigenen Klasse zu transportieren (Skinny = TCP ==> in der LLQ mit Policer = schlecht!) ==> Skinny kaputt von Normalen Traffic = schlecht ! class match-all skinny match dscp cs3 af31 ! wie sieht die ACL VOICE aus? wird hier verschlüsselt? AF31(CS3) siehe DSCP 46 (switch / port trust..) ==> mit match-any klaut natürlich die ACL Zeile das Af31 von VPN
  21. daking

    876 Router

    Hallo, am Eingangsinterface setzt du via service-policy die QOS Group: class meine set qos-group 500 ==> am Ausgangsinterface kannst du dann das Queueing nach qos-group 500 machen. (Kann man sich wie einen IOS internen DSCP Wert vorstellen) In deinem Fall sollten die relevanten Pakete schon mit den richtigen DSCP Werten versehen sein (falls CCM richtig konfiguriert). Da nach IPSEC Standard der DSCP Wert in den nächsten Header übernommen (falls tunnel mode) wird ,musst du dir keinen Stress machen. Ein Klassifizieren nach DSCP Werte sollte in dieser Konstellation reichen. Falls du natürlich nach IP Adressen + DSCP Werte am Ausgangsinterface klassifizierst, sollte man sich gedanken machen wann QOS passiert und ob die richtigen IP Adressen für das CBWFQ noch sichtbar sind... ciao
  22. daking

    876 Router

    Hallo, in meinem Fall "markiere" ich am eingangsinterface bestimmten Traffic, den ich nicht via DSCP Remarken will über die QOS Group. Diese "Markierung ist Router intern. Am Ausgangsinterface (hier NAT + IPSEC) kann ich die verschlüsselten Daten dan wieder finden und priorisieren. Ist für die DSL QOS Funktion jedoch uninteressant. ciao
  23. Hola, ja das ist dann eher suboptimal... die prim / sec root im layer 2 segment wird über die Bridge Prio bestimmt ==> die niedrigste prio gewinnt. (falls gleiche Prio läufts anders). Im optimalen Fall sollte die Rootbridge dann auf der im Normallfall aktiven HSRP / GLBP / ... Komponente liegen. Die Rootbridges kannst du so finden: SWITCH#sh spanning-tree root Root Hello Max Fwd xxxx Instance Root ID Cost Time Age Dly Root Port ---------------- -------------------- --------- ----- --- --- ------------ VLAN 100 4097 001f.9d86.7c00 20000 2 20 15 Gi0/23 SWITCH# ==> Root hat eine Prio von 4097 ==> Root Port = Gig0/23 ==> Kosten zur Root sind 20000 (hier 802.1t) ==> weiter nun wer an gig0/23 verbunden sind. ==> telnet x.x.x.x DISTRIBUTION#sh spanning-tree root Root Hello Max Fwd MST Instance Root ID Cost Time Age Dly Root Port ---------------- -------------------- ------ ----- --- --- ---------------- vlan100 4097 001f.9d86.7c00 0 2 20 15 DISTRIBUTION# ==> Root Cost = 0 ==> rootbridge ==> keine rootports ==> Root identifiziert DISTRIBUTION#sh spanning-tree xxx Spanning tree enabled protocol Root ID Priority 4097 Address <> This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 4097 (priority 4096 sys-id-ext 0) Address <> Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec logische STP Ports pro Box cat4k: Bei per VLAN STP muss pro aktivierten VLAN auf jedem Port für den Link BPDUs generiert werden. Das Generieren der BPDUs wird durch das 4k Design natürlich auf der SUP gesteuert. Die SUP hat für diesen Task bergrenzte Ressourcen (max 1500 - 3000 Pro Box ==> what sup...). ==> Für n VLANs auf einem Trunkport müssen n BPDUs pro VLAN erzeugt werden ==> Trunks ==> n VLANs erlabt = N logische Ports ==> Falls nun ein GEC konfiguriert wird ==> N * links logische Ports ==> Accessport ==> 1 VLAN ist erlaubt = 1 logischer Port ==> Accessport + IP Phone ==> 2 VLANs = 2 logische Ports LALA#sh spanning-tree summary totals Name Blocking Listening Learning Forwarding STP Active ---------------------- -------- --------- -------- ---------- ---------- 12 vlans 0 0 0 278 278 LALA# hope this hepls..
  24. Hallo, generell sollte es ja zu keinen Loops im non Accessbereich kommen. Bei der Konfiguration zur zusätzlichen Absicherung der Topo bist du auf dem richtigen Weg. Zusätzlich kann man noch storm-control (vorsicht bei 4k blocking Linecards ==> dort wird storm-control in software gehandelt. Auf dem 3560 immer über den ASIC) aktivieren, um den GAU zu verhindern. Auf den Uplinks sollte man UDLD aktivieren (aggressiv). Ein sauberes Placement der primary / secundary root setzte ich jetzt mal vorraus. Natürlich sollte man die maximalen logischen Ports nicht überschreiten (zwischen 1500 - 3000 [1.d | 1.w] ==> kommt auf die SUP an).. hope this helps
  25. Hallo, probiers mal so: ftp-server enable ftp-server topdir flash: username ftpuser pass | sec ftppass ciao – okay. der ftp-server command wurde wegen 2Sicherheitsproblemen" (:-) aus aktuellen Rel removed..... ==>scp? ciao
×
×
  • Neu erstellen...