bernd.zschill

Hallo alle zusammen,

obwohl STP bei Etherchannel keine Rolle spielt, sollte es sauber aufgesetzt werden (mstp-instanz 0 für alle vlan, ID 0).

Zweck: Sollte ein Multiventor-Adapter zweifelhafter Herkunft (ID-0) im Netz erscheinen (hatten wir schon !) spielt das Netz .... und bereitet unnötig Kopfschmerzen.

Gruß

B

Hallo,

Danke, dann werde ich das Thema etwas lockerer angehen.

 

Eine kleine Firewall mit dynamischer Portöffnung zu den Voice-Netzen an einen Switch mit Verbindung zu beiden Systemen sollte dann keine Schwierigkeiten machen?

Gruß an Alle

Bernd

Hallo alle zusammen,

Mein System läuft noch immer sehr stabil.

 

Hat schon Jemand auf ein VSS- System UCM- Cluster integriert ?

 

Ich habe eine übersichtliche Menge L2-Policy mit VLAN- Bezug, ohne Prio zu laufen.

 

Gibt es Erfahrungen hinsichtlich der üblichen QoS- Voice-Level, werden übliche handgestrickte Policy zerlegt??

 

Gruß Bernd

Hallo,

bin wieder im Land.

Auf den ersten Blick sollte es funktionieren, wenn der ping bis zu google ging.

Ich gehe davon aus, dass es ein tracerroute/tracert war, der zeigt nur die Hardware-Adressen auf dem Wege zum Ziel, nicht verfügbare virtuelle Adressen. Auf einem Ping auf die IP-Adressen sollten die beiden Teile und die Virtuelle Adresse antworten.

 

Im Weiteren ist von einer Backup-Leitung die Rede. Wenn kein Loadbalancing gekauft wurde, kann sie im Standby liegen oder aber Sende- und Empfangsrichtung werden verteilt. Genaueres siehst Du über mit einem Free-Sniffer(Wireshark o.ä.) am Monitor-/Mirrorport (musst Du noch konfigurienen).

 

Mit einer harten Prüfung (abwechselnd Netzstecker ziehen) wird der Kunde nicht einverstanden sein.

 

Gruß

Bernd

Hallo Lars,

Unterhaltung ist per Tel. über 0170-7617775 und e-mail: bernd.zschill@googlemail.com möglich.

 

Channel group on ist pagp ohne protocol negotiation

Channel group aktive ist mit protokoll negotation zu lacp (ieee-standart in Multiventor Umgebung, haben wir auch !)

Channel group desirable ist pagp mit protocol negotiation zu Cisco-Umgebung (haben wir auch !)

 

 

Notwendigkeit der erforderlichen Änderung der channelgroup mode resultiert aus der Tatsache, dass mit VSS im 65xx die Channel group pagp+ spricht. Somit gibt es gelegendlich inkompatible protocol Darstellungen zu üblichen pagp, eine negotiation ist erforderlich.

Über den inhaltlichen Unterschied von pagp und pagp+ habe ich bisher nichts gelesen.

 

Hier noch Beispiele

switch virtual domain 100

switch mode virtual

switch 1 priority 110

switch 2 priority 100

switch 1 preempt 7

dual-active pair interface GigabitEthernet1/5/1 interface GigabitEthernet2/5/1 bfd

 

interface GigabitEthernet1/1/8

switchport

switchport trunk encapsulation dot1q

switchport mode trunk

channel-group 23 mode active

 

interface GigabitEthernet1/1/13

switchport

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,10,11,50,100

switchport mode trunk

channel-group 10 mode active

 

interface GigabitEthernet1/1/24

switchport

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,50,51,55,60,61,70,71,80,100

switchport mode trunk

speed nonegotiate

flowcontrol receive on

channel-group 30 mode active

 

Gruß Bernd

Hallo Erazer,

das Problem kommt mir bekannt vor. Bei mir war die Ursache fehlerhafte Leitungen vom VSS- Link bzw. dual active Detection.

Bei Fehler wird das Standby Gehäuse automatisch zum Master, der alte Master fährt in Standby. Bei Uplink Channelgroup mode active merkt die sekundäre Ebene der Infrastruktur davon kaum etwas.

Nach Ablauf der Preemt- Zeit rebootet das System automatisch und stellt die konfigurierten Rolen wieder her. Ohne Preemt kann man auch leben, dann erfolgt der Reboot/ Rolenwechsel beim nächsten Fehler. Ein handischer Reset ist eigendlich nicht erforderlich, das System läuft weiter.

 

Ich würde den dual-active detection Link permanent überwachen, ggf. eine Umschaltung der Leitung vornehmen, sowie dual-active detection (BFD/ Channelgroup) gründlich funktionell prüfen.

 

Mit IPX habe ich kaum praktische Erfahrung. In der Syslog sehe ich vor dem Reset einen Eintrag "IP-V6 Address kann nicht addiert" werden. Kann es in Zusammenhang mit IPX stehen, oder ist es ein MS-Vista Client?

IP-V6 muss gesondert konfiguriert werden, die Konsistenz des Table´s ist wichtig!

 

Gruß

Bernd

Hallo Pastors,

ich hoffe, Ihr habt es hinbekommen und es läuft jetzt.

 

Wichtig ist die Vorbereitung, das IP-Konzept. Durch die Anzahl der Adressen in den einzelnen VLAN werden die Netzmasken bestimmt. Mit einer zu großen Netzmaske wird die vorherige Teilung wieder aufgehoben.

 

Mit einen kleinen Hilfsmittel, wie einen Kalkulator, fällt der Fehler schon beim Konzept auf (es geht auch per Hand, ist aber aufwendiger).

Gruß

Bernd

Hallo,

ein kleines IP-Konzept entwickeln, subneting per IP-subnetz calculator die Adressbereiche bestimmen. Da Provider in der Regel ein privates Netz mit 24-Bit Netzmaske bereitstellen, der Router local die Adresse 193.168.0.1 /24 (mal nachschauen) führt, kann dieses Netz gut in 8 Subnetze zu je 30 Host geteilt werden. Die Sache ist in jeden fall mit dem Serveradmin (DHCP ranges und Optionen müssen mit dem Subneting des LAN in Übereinstimmung sein) abzustimmen.

 

die config könnte dann etwa so aussehen (ohne policy per ACL , vlan access-map usw.):

 

ip routing

 

interface vlan 1 (Vlan in dem Versatel - Interface stehen)

ip address 192.168.0.2 255.255.255.224

no shutdown

 

interface vlan 100

ip address 192.168.0.33 255.255.255.224

ip helper address (Ip des DHCP-Servers)

no shutdown

 

Interface vlan 200

ip address 192.168.0.65 255.255.255.224

ip helper address (Ip des DHCP-Servers)

no shutdown

 

usw.

ip route 0.0.0.0 0.0.0.0 192.168.0.1 (locale IP des Versatel)

 

dem Voice Vlan solltest Du ggf. ein Qos mitgeben, Cisco bietet da eine "vorgefertigte Lösung" VOIP im config menue.

Aber dazu besser noch das Manual lesen und die lokale VOIP Lösung genau betrachten. QoS ist nicht ganz problemfrei.

 

Gruß

Bernd

Hallo Thomas,

Service Module sind derzeit noch kein Thema bei uns. Es gibt im Management derzeit keine Begeisterung für Alles, was Geld kostet.

Es wird gewiss einen Zeitpunkt für Akzeptanz dieser Vorteile geben.

 

VSS wurde abgesegnet, da zwingend ein Ersatz her musste. Den Vorteil, zweier aktiver Komponenten gegenüber üblicher Hot-standby Lösungen, hat man begrüßt, zumal die Lösung in dieser Leistungsklasse kostengünstig ist.

 

Gruß

Bernd

Hallo,

so toll ist die Idee nicht. Im access mode bedient er nur ein vlan, ohne weitere Angabe default vlan, der rest bleibt auf der Strecke, altenativ die vorherige Trennung wird aufgehoben.

In dem Umfeld kann der 3560 aber gut einen Router darstellen, der die vlan und das SERSATEL- Teil routed.

hallo veteranß und newbie´s

mein VSS-System arbeitet jetzt sehr stabil.

Folgender Hinweis: Uplink across über C3750 Stack funktionieren nur im channelgroup mode active.

 

Im Sommer soll ein C3750-IOS mit pagp+ kommen. Geht dann mode on wieder und/oder wir das Problem mode desirable für PO´s across eines Stack gelöst.

 

Gruß, ich erwarte Hinweise/ stehe für Fragen zur Verfügung

Hallo, besten Dank für die Tip´s.

Gestern sind wir mit Koll von Cisco die Punkte durchgegangen:

 

1.VSS- Steuerung:

Es ist kein Bug, es ist ein Feature. In Erklärung einleuchtend, am System beliebig oft nachvollziehbar:

 

- Bei Ausfall VSLink geht das System (der Active-1) von einem Fehler im System, nicht nur physischen/L2-Fehler aus!

Da der dual-active noch den Peer- Hardwareswitch sieht, schaltet der Active-1 all seine Line Card down, sein Management bleibt aktiv (Ich hab dann 2 Con CLI/ aber nur ein vty zur Verfügung - kann per sh swi virt red den Erreichten anzeigen lassen).

- Dem Standby- Switch wird unterstellt, dass er OK ist - er hatte bisher noch nichts eigenständig getan, alle Forwrdinginformationen wurden vom Active-1 bezogen, seine Interface sind oben. Er wird zum Activen, erarbeitet die Forwarding Info´s selbständig weiter, der alte Active-1 ist durch fehlende Linie Card blind.

- Mit UP von VSL-Link sieht der ehemalige Acitve-1 seinen Peer wieder, prüft sein System durch einen automatischen Reboot mit Selftest und landet gewollt in der Standby-Role.

Da stimmt sich das System ab und nach preemt wird Sw-1 Active, der Sw-2 bootet zum Standby.

Von dem Stress merkt der Netzverkehr, inklusive Routing usw. nichts. Ich habe Kreuzverkehr mit Solarwind´s und Brix (mit max Last) zu laufen gehabt.

 

2. Uplinkstabilität:

65xxVSS spricht pagp+, derzeit die 3750ér pagp. Damit gibt es ggf. Missverständnisse und errordisable shlägt zu. Mit Umstellen der channel-group´s auf mode desirable scheint das Problem vom Tisch zu sein. Ich habe nichts mehr gesehen.

 

Gruß an ALLE

hallo, hier CLI

 

#sh switch virtual role

 

Switch Switch Status Preempt Priority Role Session ID

Number Oper(Conf) Oper(Conf) Local Remote

------------------------------------------------------------------

LOCAL 1 UP TRUE (Y*) 110(110) ACTIVE 0 0

REMOTE 2 UP FALSE(N ) 100(100) STANDBY 8071 4985

 

Active configured preempt timer(switch 1): 7 minutes

 

 

In dual-active recovery mode: No

 

 

sh switch virtual link

VSL Status : UP

VSL Uptime : 23 hours, 27 minutes

VSL SCP Ping : Pass

VSL ICC Ping : Pass

VSL Control Link : Te1/5/4

 

 

sh switch virtual redundancy

My Switch Id = 1

Peer Switch Id = 2

Last switchover reason = none

Configured Redundancy Mode = sso

Operating Redundancy Mode = sso

 

Switch 1 Slot 5 Processor Information :

-----------------------------------------------

Current Software state = ACTIVE

Uptime in current state = 23 hours, 27 minutes

Image Version = Cisco IOS Software, s72033_rp Software (s72033_rp-ADVIPSE

RVICESK9_WAN-VM), Version 12.2(33)SXH2a, RELEASE SOFTWARE (fc2)

Technical Support: Cisco - Shortcut

Copyright © 1986-2008 by Cisco Systems, Inc.

Compiled Fri 25-Apr-08 21:00 by prod_rel_team

BOOT =

CONFIG_FILE =

BOOTLDR =

Configuration register = 0x2102

Fabric State = ACTIVE

Control Plane State = ACTIVE

 

Switch 2 Slot 5 Processor Information :

-----------------------------------------------

Current Software state = STANDBY HOT (switchover target)

Uptime in current state = 23 hours, 27 minutes

Image Version = Cisco IOS Software, s72033_rp Software (s72033_rp-ADVIPSE

RVICESK9_WAN-VM), Version 12.2(33)SXH2a, RELEASE SOFTWARE (fc2)

Technical Support: Cisco - Shortcut

Copyright © 1986-2008 by Cisco Systems, Inc.

Compiled Fri 25-Apr-08 21:00 by prod_rel_team

BOOT =

CONFIG_FILE =

BOOTLDR =

Configuration register = 0x2102

Fabric State = ACTIVE

Control Plane State = STANDBY

 

 

Mein Problem vermute ich in dem Fakt, dass ich das dual-active pair bfd konfigurieren kann,

jedoch nicht die beiden Interface dual-active excluden kann.

 

(config-vs-domain)#$ exclude interface gigabitEthernet 1/5/1

Cannot configure exclusion on bfd dual-active interface

 

Wenn exclude, dann nach pair- Auflösung. Danach geht jedoch kein dual-active pair mehr ...

 

Damit geht mit der standby- Umschaltung nach VSL- Unterbrechung auch das dual-active pair down. Eine Saubere Art mir eine Schleife zu basteln ...

Hallo,

natürlich ist die Sache sehr hot. Mein kleines Problem:

der VSL geht down - der dual-aktive bfd greift und schickt den VSS-Master down, der Standby wird Master ...

Trotz preemt muss ich die Zuordnung per reload mit beiden wiederherstellen.

 

Hat einer DIE IDEE ?