daking
-
Gesamte Inhalte
595 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von daking
-
-
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.
-
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 (;-)
-
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
-
stell mal das eth interface zum DSL Modem auf auto/auto ==> wie steht das interface dann FDX / HDX?
-
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?
-
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
-
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.....
-
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
-
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.
-
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.
-
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.
-
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.
-
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....
brgds
TS
-
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
-
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
//
-
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
//
-
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
-
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
-
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
-
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
-
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
-
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..
-
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
-
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
Mpls Vpn
in Cisco Forum — Allgemein
Geschrieben
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