EtherChannel Problem

[Operator 10]

Hi Leute,

 

habe gerade mit unserem neuen schönen IBM Server rumgespielt und an den beiden Netzwerk-Ports mal "Teaming" aktiviert via 802.3ad als Link-Aggregation.

 

Dasselbe Spiel hab ich an meinem Catalyst 3550 gemacht und an den beiden Ports (mit Namen fa0/30 und fa0/32) folgendes eingerichtet:

 

interface FastEthernet0/30

switchport access vlan 999

channel-group 1 mode on

!

interface FastEthernet0/32

switchport access vlan 999

channel-group 1 mode on

 

interface Port-channel1

switchport access vlan 999

 

 

Soweit so gut... am Switch hab ich im VLAN 999 wunderbar Netzwerk-Verbindung und kann alle anderen Server anpingen, die am selben Switch hängen.

 

Nur andere Hosts an anderen Switches kann ich nicht erreichen.

 

Trunking an den Gigabit Ports zum Backbone ist eingerichtet und funktioniert für einzelne Ports im VLAN 999 auch wunderbar.

 

Hat jemand ne spontane Idee woran's liegen könnte?

 

Vielen Dank schon mal

 

Andre aka Operator

[andif 10]

Hallo,

 

hab ich das richtig verstanden - du kommst im vlan999 überall hin aber nicht raus ? Wenn ja dann solltest du dir mal das Routing zu den anderen vlans anschauen.

[Operator 10]

Hi andif,

 

nicht ganz! VLAN999 funktioniert nur am Switch selbst, so daß es für mich nach einem VLAN Trunking Problem aussieht.

 

Ich erreiche also nicht alle Hosts im VLAN.. nur die, die am selben Switch hängen.

Das ganze funktioniert aber mit den normalen fastEthernet Ports...

 

Noch ne Idee?

 

Andre aka Operator

[andif 10]

Hey,

 

poste mal die Config von den Uplinkports und auch die Config der Ports auf der anderen Seite.

 

Andi

[Frank04 10]

Was hängt dem im Edge Bereich ? Ist denn dort auch das entsprechende VLAN eingerichtet und tagged der Uplink-Port ?

[Operator 10]

So. Sorry, daß ich mich lang nicht gemeldet hab, aber ohne die Configs aus der Firma bringt posten ja auch nichts :-)

 

Aber die liefere ich nun nach!

(teilweise zusammengeschnitten, wenn was fehlt, bitte melden)

 

Cisco 6000 - A

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

set vlan 999 name Transfer type ethernet mtu 1500 said 100999 state active

set spantree priority 8192 999

set trunk 3/5 on dot1q 1-1005,1025-4094

 

Cisco 6000 - A - MSFC Module

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

interface Vlan999

description Transfer VLAN

ip address 172.29.254.198 255.255.0.0

no ip redirects

standby 99 priority 110 preempt

standby 99 ip 172.29.254.200

 

Cisco 6000 - B

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

set vlan 999 name Transfer type ethernet mtu 1500 said 100999 state active

set spantree priority 16384 999

set trunk 3/5 on dot1q 1-1005,1025-4094

 

Cisco 6000 - B - MSFC Module

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

interface Vlan999

description Transfer VLAN

ip address 172.29.254.199 255.255.0.0

no ip redirects

standby 99 ip 172.29.254.200

 

So jeweils am Port 3/5 der 6000er hängen nun die beiden Gigabit Ports des Catalyst 3550:

 

interface GigabitEthernet0/1

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,330,331,999,1002-1005

switchport mode trunk

no ip address

udld enable

spanning-tree portfast

!

interface GigabitEthernet0/2

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,330,331,999,1002-1005

switchport mode trunk

no ip address

udld enable

spanning-tree portfast

!

interface FastEthernet0/30

switchport access vlan 999

channel-group 1 mode on

!

interface FastEthernet0/32

switchport access vlan 999

channel-group 1 mode on

 

interface Port-channel1

switchport access vlan 999

 

 

Mit einem normalen Switchport im VLAN999 klappt jede Verbindung auch sehr gut (seit 2 Jahren etwa), selbst das IP FailOver des Gateways funktioniert samt Spanning-Tree.

 

Nur im PortChannel komme ich nicht über den Switch hinaus.

Ich hab auch schon mal probiert das PortChannel Interface zum Trunk zu machen und VLAN Tagging auf der Netzwerkkarte aktiviert. Das brachte aber leider auch nichts :(

 

Noch jemand ne Idee?

 

Vielen Dank schon mal.

Andre

[n@ppo 10]

hi,

 

mit welcher mac-adresse kommt deine nic im teaming-mode bzw. im trunking. ist das eine multicast oder unicast ?

 

da du von anderen end-devices aus dem vlan 999 vom cat 3550 über den trunk kommst kannst du ein generelles trunking-problem ausschließen (zumindest lese ich das so heraus).

 

ich tippe mal auf eine problem mit der mac-adresse des teaming-adapters im teaming-mode.

 

ähnliche probleme gibt es beim einsatz von diversen clustern (z.b. stonebeat, nokia, etc). das problem dort ist das eine multicast-mac zu einer unicast ip gemapped ist.

normalerweise sollte dies kein problem sein (im layer 2 eh nicht)

es ist aber von cisco recommended das für solche zwecke statische arp bzw. statische mac einträge gemacht werden sollen/müssen.

 

weiterhin sollten für diesen fall auch acl´s auf den hsrp-routern laufen und igmp-snooping auf den betreffenden switches ausgeschaltet werden.

 

ach so noch etwas:

portfast auf einem trunk kann böse ins auge gehen.

[Operator 10]

Hi n@ppo,

 

danke schon mal für die Tipps :)

 

Mit Portfast könntest Du recht haben :) Ist n Austauschgerät für n defekten 3548 gewesen. Wahrscheinlich hatte ichs damals konfiguriert nur bei der Übernahme der Config vergessen :)

Sollte ich mal rausnehmen...

 

Ich werd morgen mal schauen, welche MAC Adresse er vorschlägt, wenn ich den Teaming Modus aktiviere.

Momentan möchte ich nicht so gern an den Server ran, da noch ca. 80 Leute via Terminal Services draufrumnudeln :)

Werd mich also morgen noch mal deswegen melden!

 

Werde mir dann auch die Einträge der mac-address-table anschauen, vielleicht entdecke ich ja was!

 

Wie darf ich die Sache mit den ACLs auf den HSRP Routern verstehen? HSRP nur für die Router erlauben?

 

Andre aka Operator

[n@ppo 10]

Wie darf ich die Sache mit den ACLs auf den HSRP Routern verstehen? HSRP nur für die Router erlauben?

 

Andre aka Operator

 

nein das meinte ich anders,

 

das problem ist das bei einem cluster mit multicast-mac-adressen in verbindung mit hsrp die paktet dupliziert werden (könnten)

das hat cisco noch nie wirklich in den griff bekommen.

 

bei folgendem aufbau:

 

R1-- --clusterengine1

|--|

R2-- --clusterengine2

 

wenn ein pakete durch die/den router "läuft" z.b. R1. dann wird er das paket an die unicast-ip/multicast-mac des cluster adressieren (z.b 0300.0815.4711)

das pakete kommt außerdem bei R2 an. dieser sollte eigentlich das paket ignorieren. dies machen diverse ios-versionen aber nicht, sondern das paket durchläuft abermals die routinginstanz wird im ttl dekrementiert und auf die reise in richtung cluster geschickt.

das paket kommt also wieder am cluster an ....und bei R1. er schickt nun abermals eine kopie an das cluster und dekremintiert das ttl ....das paket kommt beim cluster an und natürlich wieder mal bei R2. das spiel geht solange bis das ttl heruntergezählt ist.

 

das hat der effekt das du z.b. bei einem firewall-cluster sehr viele dupletten bekommst. und die firewall hier und da probleme macht :D.

 

das ganze kannst du umgehen indem du eine acl (incoming) auf den router definierst wo als ziel das firewall-cluster ausgeschlossen wird.

 

da du bei dir mit nur einem gerät/nic arbeitest muß dies keine folgen haben.

wenn du allerdings mit einer unicast ip arbeitest und einer multicast-mac daher kommst von deiner nic. dann benötigst du mindestens einen statischen arp eintrag auf der msfc , sonst wirst du über dein vlan999 nicht hinaus kommen.

das mapping einer unicast ip zu einer multicast mac ist wenn ich mich recht entsinne laut rfc 1812 nicht zwingend erlaubt.

 

und eben dieses " ein router kann eine unicast ip zu einer multicast-mac mappen" macht cisco seit der version 11.3 nicht mehr.

ich schätze mal das es eine security maßnahme ist (oder eine vertriebstechnische)