Hi there,
Maybe there are some Cisco specialists reading this List =)
On a WS-C3750X it tooks about 1 minute after connecting a port to change the status from LINK-3-UPDOWN "up" to LINEPROTO-5-UPDOWN "up"
Mar 27 16:25:37 192.168.1.144 788: *Mar 8 00:30:48.032: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Mar 27 16:26:38 192.168.1.144 790: *Mar 8 00:31:49.227: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to up
Mar 27 16:25:54 192.168.1.144 789: *Mar 8 00:31:05.086: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Mar 27 16:26:56 192.168.1.144 791: *Mar 8 00:32:06.583: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/1, changed state to up
The ports are configured like that:
interface GigabitEthernet1/0/1 switchport access vlan 27 switchport mode access spanning-tree portfast spanning-tree bpdufilter enable channel-group 1 mode active ! interface GigabitEthernet2/0/1 switchport access vlan 27 switchport mode access spanning-tree portfast spanning-tree bpdufilter enable channel-group 1 mode active ! interface Port-channel1 switchport access vlan 27 switchport mode access end
The server which is connected has nothing special configured... It should boot via DHCP/PXE (of course without Bonding) and then the installed Linux with Bonding configured. Does anyone have an idea why this takes so long?
Thanks!
Cheers, Tobias
One thing to watch out in VLAN config is that DHCP broadcasts are sent in the default VLAN, not the tagged VLAN. But I'm not sure how this applies to access ports. I remember however that I once expected DHCP requests to come in on the tagged VLAN on the router (which was DHCP server) but they did come in untagged and later discovered that the standard is defining this (odd) behaviour.
Also as they are broadcasts, the "ip helper" command can help you to get DHCP over layer 3. Most cisco switches do support it and it is actually useful to set it so DHCP broadcasts are being directed to the DHCP server immediately.
On 03.04.2012, at 09:24, Tobias Brunner wrote:
Hi there,
Maybe there are some Cisco specialists reading this List =)
On a WS-C3750X it tooks about 1 minute after connecting a port to change the status from LINK-3-UPDOWN "up" to LINEPROTO-5-UPDOWN "up"
Mar 27 16:25:37 192.168.1.144 788: *Mar 8 00:30:48.032: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Mar 27 16:26:38 192.168.1.144 790: *Mar 8 00:31:49.227: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to up
Mar 27 16:25:54 192.168.1.144 789: *Mar 8 00:31:05.086: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Mar 27 16:26:56 192.168.1.144 791: *Mar 8 00:32:06.583: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/1, changed state to up
The ports are configured like that:
interface GigabitEthernet1/0/1 switchport access vlan 27 switchport mode access spanning-tree portfast spanning-tree bpdufilter enable channel-group 1 mode active ! interface GigabitEthernet2/0/1 switchport access vlan 27 switchport mode access spanning-tree portfast spanning-tree bpdufilter enable channel-group 1 mode active ! interface Port-channel1 switchport access vlan 27 switchport mode access end
The server which is connected has nothing special configured... It should boot via DHCP/PXE (of course without Bonding) and then the installed Linux with Bonding configured. Does anyone have an idea why this takes so long?
Thanks!
Cheers, Tobias
-- Nine Internet Solutions AG, Albisriederstr. 243a, CH-8047 Zuerich Support +41 44 637 40 40 | Tel +41 44 637 40 00 | Direct +41 44 637 40 13 Skype nine.ch_support
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Hello Tobias
Try to configure following and you should get better results:
interface Port-channel1 switchport access vlan 27 switchport mode access spanning-tree portfast spanning-tree bpdufilter enable end
Regards
Kurt
.:|:.:|:. cisco Kurt Mathys|Systems Engineer |o:+41 44 878 9212|m:+41 79 419 5810 | kmathys@cisco.com
-----Original Message----- From: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] On Behalf Of Tobias Brunner Sent: Dienstag, 3. April 2012 09:24 To: Swinog Subject: [swinog] EtherChannel - Long Time between LINK-3-UPDOWN andLINEPROTO-5-UPDOWN
Hi there,
Maybe there are some Cisco specialists reading this List =)
On a WS-C3750X it tooks about 1 minute after connecting a port to change the status from LINK-3-UPDOWN "up" to LINEPROTO-5-UPDOWN "up"
Mar 27 16:25:37 192.168.1.144 788: *Mar 8 00:30:48.032: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Mar 27 16:26:38 192.168.1.144 790: *Mar 8 00:31:49.227: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to up
Mar 27 16:25:54 192.168.1.144 789: *Mar 8 00:31:05.086: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Mar 27 16:26:56 192.168.1.144 791: *Mar 8 00:32:06.583: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/1, changed state to up
The ports are configured like that:
interface GigabitEthernet1/0/1 switchport access vlan 27 switchport mode access spanning-tree portfast spanning-tree bpdufilter enable channel-group 1 mode active ! interface GigabitEthernet2/0/1 switchport access vlan 27 switchport mode access spanning-tree portfast spanning-tree bpdufilter enable channel-group 1 mode active ! interface Port-channel1 switchport access vlan 27 switchport mode access end
The server which is connected has nothing special configured... It should boot via DHCP/PXE (of course without Bonding) and then the installed Linux with Bonding configured. Does anyone have an idea why this takes so long?
Thanks!
Cheers, Tobias
-- Nine Internet Solutions AG, Albisriederstr. 243a, CH-8047 Zuerich Support +41 44 637 40 40 | Tel +41 44 637 40 00 | Direct +41 44 637 40 13 Skype nine.ch_support
_______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Hi tobias,
make sure that you only put the physical interfaces into portchannel, rest of the config is done on your portchannel. It get's replicated to the physical interfaces. If you change something directly on the gig he will bring down the etherchannel :/ (complain about different configuration between portchan and gig)
-steven
-----Ursprüngliche Nachricht----- Von: swinog-bounces@lists.swinog.ch [mailto:swinog- bounces@lists.swinog.ch] Im Auftrag von Tobias Brunner Gesendet: Dienstag, 3. April 2012 09:24 An: Swinog Betreff: [swinog] EtherChannel - Long Time between LINK-3-UPDOWN and LINEPROTO-5-UPDOWN
Hi there,
Maybe there are some Cisco specialists reading this List =)
On a WS-C3750X it tooks about 1 minute after connecting a port to change the status from LINK-3-UPDOWN "up" to LINEPROTO-5-UPDOWN "up"
Mar 27 16:25:37 192.168.1.144 788: *Mar 8 00:30:48.032: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Mar 27 16:26:38 192.168.1.144 790: *Mar 8 00:31:49.227: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to up
Mar 27 16:25:54 192.168.1.144 789: *Mar 8 00:31:05.086: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Mar 27 16:26:56 192.168.1.144 791: *Mar 8 00:32:06.583: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/1, changed state to up
The ports are configured like that:
interface GigabitEthernet1/0/1 switchport access vlan 27 switchport mode access spanning-tree portfast spanning-tree bpdufilter enable channel-group 1 mode active ! interface GigabitEthernet2/0/1 switchport access vlan 27 switchport mode access spanning-tree portfast spanning-tree bpdufilter enable channel-group 1 mode active ! interface Port-channel1 switchport access vlan 27 switchport mode access end
The server which is connected has nothing special configured... It should boot via DHCP/PXE (of course without Bonding) and then the installed Linux with Bonding configured. Does anyone have an idea why this takes so long?
Thanks!
Cheers, Tobias
-- Nine Internet Solutions AG, Albisriederstr. 243a, CH-8047 Zuerich Support
+41
44 637 40 40 | Tel +41 44 637 40 00 | Direct +41 44 637 40 13 Skype nine.ch_support
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Hi all,
Thanks for the input so far. I've merged all the input of you (and the trunk/vlan configuration I need to use) and this is how the configuration looks right now:
interface GigabitEthernet1/0/1 switchport trunk encapsulation dot1q switchport trunk native vlan 27 switchport trunk allowed vlan 27,453 switchport mode trunk no cdp enable spanning-tree portfast trunk spanning-tree bpdufilter enable channel-group 1 mode active ! interface GigabitEthernet2/0/1 switchport trunk encapsulation dot1q switchport trunk native vlan 27 switchport trunk allowed vlan 27,453 switchport mode trunk no cdp enable spanning-tree portfast trunk spanning-tree bpdufilter enable channel-group 1 mode active ! interface Port-channel1 switchport trunk encapsulation dot1q switchport trunk native vlan 27 switchport trunk allowed vlan 27,453 switchport mode trunk spanning-tree portfast trunk spanning-tree bpdufilter enable end
It's not possible to just configure the "channel-group" on the GiX interfaces and all the rest on Po1 (as suggested by Steven), I had to add at least the "switchport" settings (otherwise the switch complains about not compatible ports). The addition of the spanning-tree settings to Po1 did not change the behaviour either. Also the used cables should be OK.
And now, when I power on the server, this is the output of the switch-log (The server boots from Network, then from local disk with Debian and bonding configured:
Apr 4 09:00:06 192.168.1.144 152: *Mar 15 17:05:41.781: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:06 192.168.1.144 153: *Mar 15 17:05:41.781: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:00:15 192.168.1.144 154: *Mar 15 17:05:51.202: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:00:16 192.168.1.144 155: *Mar 15 17:05:52.250: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:00:17 192.168.1.144 156: *Mar 15 17:05:53.525: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:18 192.168.1.144 157: *Mar 15 17:05:54.607: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:00:30 192.168.1.144 158: *Mar 15 17:06:05.907: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:00:30 192.168.1.144 159: *Mar 15 17:06:05.924: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:00:32 192.168.1.144 160: *Mar 15 17:06:08.465: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:32 192.168.1.144 161: *Mar 15 17:06:08.482: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:00:47 192.168.1.144 162: *Mar 15 17:06:22.701: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:00:47 192.168.1.144 163: *Mar 15 17:06:22.718: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:00:49 192.168.1.144 164: *Mar 15 17:06:25.050: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:49 192.168.1.144 165: *Mar 15 17:06:25.285: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:00:54 192.168.1.144 166: *Mar 15 17:06:29.957: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:00:54 192.168.1.144 167: *Mar 15 17:06:30.116: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:00:56 192.168.1.144 168: *Mar 15 17:06:32.515: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:56 192.168.1.144 169: *Mar 15 17:06:32.641: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:01:35 192.168.1.144 170: *Mar 15 17:07:10.768: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:01:37 192.168.1.144 171: *Mar 15 17:07:13.125: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:01:59 192.168.1.144 172: *Mar 15 17:07:35.430: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:02:39 192.168.1.144 173: *Mar 15 17:08:15.142: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:02:56 192.168.1.144 174: *Mar 15 17:08:32.246: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:02:56 192.168.1.144 175: *Mar 15 17:08:33.253: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:03:00 192.168.1.144 176: *Mar 15 17:08:35.753: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:03:15 192.168.1.144 177: *Mar 15 17:08:51.649: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:03:16 192.168.1.144 178: *Mar 15 17:08:52.446: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:03:16 192.168.1.144 179: *Mar 15 17:08:52.672: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:03:19 192.168.1.144 180: *Mar 15 17:08:54.979: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:03:37 192.168.1.144 181: *Mar 15 17:09:13.308: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:04:22 192.168.1.144 182: *Mar 15 17:09:57.835: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:04:23 192.168.1.144 183: *Mar 15 17:09:58.825: %LINK-3-UPDOWN: Interface Port-channel1, changed state to up Apr 4 09:04:24 192.168.1.144 184: *Mar 15 17:09:59.722: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:04:24 192.168.1.144 185: *Mar 15 17:09:59.832: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changed state to up
As you can see, the ports go up and down many times (very strange, but maybe this is "by-design"). And it takes always 1 minute between LINK-3-UPDOWN and LINEPROTO-5-UPDOWN. The thing that makes me thinking of that this should be explainable: Why does it take always 1 minute? Is there something that can be configured which causes this delay? What does the switch expect? What does it wait for?
It's nice to get good input in this mailing list! Thanks for that! =)
Cheers, Tobias
Be aware of the port-channeling protocol you use ( LACP or PAGP ) Channel-group 1 mode active -> LACP
There are timers involved to get the port-channel up.
If you are sure about which interfaces will be part of it and you don't need to define spare ports Then you could also go for a static port-channel: switchport nonegociate
Also be careful to apply your vlans on the port-channel interface only. It gets replicated to the physical interfaces.
Eric
-----Message d'origine----- De : swinog-bounces@lists.swinog.ch [mailto:swinog- bounces@lists.swinog.ch] De la part de Tobias Brunner Envoyé : mercredi 4 avril 2012 09:12 À : swinog@lists.swinog.ch Objet : Re: [swinog] EtherChannel - Long Time between LINK-3-UPDOWN and LINEPROTO-5-UPDOWN
Hi all,
Thanks for the input so far. I've merged all the input of you (and the trunk/vlan configuration I need to use) and this is how the configuration looks right now:
interface GigabitEthernet1/0/1 switchport trunk encapsulation dot1q switchport trunk native vlan 27 switchport trunk allowed vlan 27,453 switchport mode trunk no cdp enable spanning-tree portfast trunk spanning-tree bpdufilter enable channel-group 1 mode active ! interface GigabitEthernet2/0/1 switchport trunk encapsulation dot1q switchport trunk native vlan 27 switchport trunk allowed vlan 27,453 switchport mode trunk no cdp enable spanning-tree portfast trunk spanning-tree bpdufilter enable channel-group 1 mode active ! interface Port-channel1 switchport trunk encapsulation dot1q switchport trunk native vlan 27 switchport trunk allowed vlan 27,453 switchport mode trunk spanning-tree portfast trunk spanning-tree bpdufilter enable end
It's not possible to just configure the "channel-group" on the GiX interfaces and all the rest on Po1 (as suggested by Steven), I had to add at least the "switchport" settings (otherwise the switch complains about not compatible ports). The addition of the spanning-tree settings to Po1 did not change the behaviour either. Also the used cables should be OK.
And now, when I power on the server, this is the output of the switch- log (The server boots from Network, then from local disk with Debian and bonding configured:
Apr 4 09:00:06 192.168.1.144 152: *Mar 15 17:05:41.781: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:06 192.168.1.144 153: *Mar 15 17:05:41.781: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:00:15 192.168.1.144 154: *Mar 15 17:05:51.202: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:00:16 192.168.1.144 155: *Mar 15 17:05:52.250: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:00:17 192.168.1.144 156: *Mar 15 17:05:53.525: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:18 192.168.1.144 157: *Mar 15 17:05:54.607: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:00:30 192.168.1.144 158: *Mar 15 17:06:05.907: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:00:30 192.168.1.144 159: *Mar 15 17:06:05.924: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:00:32 192.168.1.144 160: *Mar 15 17:06:08.465: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:32 192.168.1.144 161: *Mar 15 17:06:08.482: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:00:47 192.168.1.144 162: *Mar 15 17:06:22.701: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:00:47 192.168.1.144 163: *Mar 15 17:06:22.718: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:00:49 192.168.1.144 164: *Mar 15 17:06:25.050: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:49 192.168.1.144 165: *Mar 15 17:06:25.285: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:00:54 192.168.1.144 166: *Mar 15 17:06:29.957: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:00:54 192.168.1.144 167: *Mar 15 17:06:30.116: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:00:56 192.168.1.144 168: *Mar 15 17:06:32.515: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:56 192.168.1.144 169: *Mar 15 17:06:32.641: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:01:35 192.168.1.144 170: *Mar 15 17:07:10.768: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:01:37 192.168.1.144 171: *Mar 15 17:07:13.125: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:01:59 192.168.1.144 172: *Mar 15 17:07:35.430: %LINEPROTO-5- UPDOWN: Line protocol on Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:02:39 192.168.1.144 173: *Mar 15 17:08:15.142: %LINEPROTO-5- UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:02:56 192.168.1.144 174: *Mar 15 17:08:32.246: %LINEPROTO-5- UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:02:56 192.168.1.144 175: *Mar 15 17:08:33.253: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:03:00 192.168.1.144 176: *Mar 15 17:08:35.753: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:03:15 192.168.1.144 177: *Mar 15 17:08:51.649: %LINEPROTO-5- UPDOWN: Line protocol on Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:03:16 192.168.1.144 178: *Mar 15 17:08:52.446: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:03:16 192.168.1.144 179: *Mar 15 17:08:52.672: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:03:19 192.168.1.144 180: *Mar 15 17:08:54.979: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:03:37 192.168.1.144 181: *Mar 15 17:09:13.308: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:04:22 192.168.1.144 182: *Mar 15 17:09:57.835: %LINEPROTO-5- UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:04:23 192.168.1.144 183: *Mar 15 17:09:58.825: %LINK-3-UPDOWN: Interface Port-channel1, changed state to up Apr 4 09:04:24 192.168.1.144 184: *Mar 15 17:09:59.722: %LINEPROTO-5- UPDOWN: Line protocol on Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:04:24 192.168.1.144 185: *Mar 15 17:09:59.832: %LINEPROTO-5- UPDOWN: Line protocol on Interface Port-channel1, changed state to up
As you can see, the ports go up and down many times (very strange, but maybe this is "by-design"). And it takes always 1 minute between LINK-3-UPDOWN and LINEPROTO-5-UPDOWN. The thing that makes me thinking of that this should be explainable: Why does it take always 1 minute? Is there something that can be configured which causes this delay? What does the switch expect? What does it wait for?
It's nice to get good input in this mailing list! Thanks for that! =)
Cheers, Tobias
-- Nine Internet Solutions AG, Albisriederstr. 243a, CH-8047 Zuerich Support +41 44 637 40 40 | Tel +41 44 637 40 00 | Direct +41 44 637 40 13 Skype nine.ch_support
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Oh hai
AFAIK "switchport nonegotiate" turns off dynamic trunking protocol and has no direct impact on bonding protocols like LACP or PAgP. Of course the bonded interfaces should have the same properties (speed, duplex mode, encapsulation) --> http://bit.ly/HZoa4L
@Tobias:
Since the line protocol doesn't come up immediately (and the interfaces even flap) I assume you have a problem with port negotiation. Have you tried specifying the duplex mode and speed of the interfaces?
interface gi 1/0/1 speed 1000 duplex full
I had to do that on several occasions when using EtherChannels (notably for NAS appliances).
HTH
Cheers!
On 4 Apr 2012, at 10:13, Eric Laporte wrote:
Be aware of the port-channeling protocol you use ( LACP or PAGP ) Channel-group 1 mode active -> LACP
There are timers involved to get the port-channel up.
If you are sure about which interfaces will be part of it and you don't need to define spare ports Then you could also go for a static port-channel: switchport nonegociate
Also be careful to apply your vlans on the port-channel interface only. It gets replicated to the physical interfaces.
Eric
-----Message d'origine----- De : swinog-bounces@lists.swinog.ch [mailto:swinog- bounces@lists.swinog.ch] De la part de Tobias Brunner Envoyé : mercredi 4 avril 2012 09:12 À : swinog@lists.swinog.ch Objet : Re: [swinog] EtherChannel - Long Time between LINK-3-UPDOWN and LINEPROTO-5-UPDOWN
Hi all,
Thanks for the input so far. I've merged all the input of you (and the trunk/vlan configuration I need to use) and this is how the configuration looks right now:
interface GigabitEthernet1/0/1 switchport trunk encapsulation dot1q switchport trunk native vlan 27 switchport trunk allowed vlan 27,453 switchport mode trunk no cdp enable spanning-tree portfast trunk spanning-tree bpdufilter enable channel-group 1 mode active ! interface GigabitEthernet2/0/1 switchport trunk encapsulation dot1q switchport trunk native vlan 27 switchport trunk allowed vlan 27,453 switchport mode trunk no cdp enable spanning-tree portfast trunk spanning-tree bpdufilter enable channel-group 1 mode active ! interface Port-channel1 switchport trunk encapsulation dot1q switchport trunk native vlan 27 switchport trunk allowed vlan 27,453 switchport mode trunk spanning-tree portfast trunk spanning-tree bpdufilter enable end
It's not possible to just configure the "channel-group" on the GiX interfaces and all the rest on Po1 (as suggested by Steven), I had to add at least the "switchport" settings (otherwise the switch complains about not compatible ports). The addition of the spanning-tree settings to Po1 did not change the behaviour either. Also the used cables should be OK.
And now, when I power on the server, this is the output of the switch- log (The server boots from Network, then from local disk with Debian and bonding configured:
Apr 4 09:00:06 192.168.1.144 152: *Mar 15 17:05:41.781: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:06 192.168.1.144 153: *Mar 15 17:05:41.781: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:00:15 192.168.1.144 154: *Mar 15 17:05:51.202: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:00:16 192.168.1.144 155: *Mar 15 17:05:52.250: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:00:17 192.168.1.144 156: *Mar 15 17:05:53.525: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:18 192.168.1.144 157: *Mar 15 17:05:54.607: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:00:30 192.168.1.144 158: *Mar 15 17:06:05.907: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:00:30 192.168.1.144 159: *Mar 15 17:06:05.924: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:00:32 192.168.1.144 160: *Mar 15 17:06:08.465: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:32 192.168.1.144 161: *Mar 15 17:06:08.482: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:00:47 192.168.1.144 162: *Mar 15 17:06:22.701: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:00:47 192.168.1.144 163: *Mar 15 17:06:22.718: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:00:49 192.168.1.144 164: *Mar 15 17:06:25.050: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:49 192.168.1.144 165: *Mar 15 17:06:25.285: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:00:54 192.168.1.144 166: *Mar 15 17:06:29.957: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:00:54 192.168.1.144 167: *Mar 15 17:06:30.116: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:00:56 192.168.1.144 168: *Mar 15 17:06:32.515: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:56 192.168.1.144 169: *Mar 15 17:06:32.641: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:01:35 192.168.1.144 170: *Mar 15 17:07:10.768: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:01:37 192.168.1.144 171: *Mar 15 17:07:13.125: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:01:59 192.168.1.144 172: *Mar 15 17:07:35.430: %LINEPROTO-5- UPDOWN: Line protocol on Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:02:39 192.168.1.144 173: *Mar 15 17:08:15.142: %LINEPROTO-5- UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:02:56 192.168.1.144 174: *Mar 15 17:08:32.246: %LINEPROTO-5- UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:02:56 192.168.1.144 175: *Mar 15 17:08:33.253: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:03:00 192.168.1.144 176: *Mar 15 17:08:35.753: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:03:15 192.168.1.144 177: *Mar 15 17:08:51.649: %LINEPROTO-5- UPDOWN: Line protocol on Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:03:16 192.168.1.144 178: *Mar 15 17:08:52.446: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:03:16 192.168.1.144 179: *Mar 15 17:08:52.672: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:03:19 192.168.1.144 180: *Mar 15 17:08:54.979: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:03:37 192.168.1.144 181: *Mar 15 17:09:13.308: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:04:22 192.168.1.144 182: *Mar 15 17:09:57.835: %LINEPROTO-5- UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:04:23 192.168.1.144 183: *Mar 15 17:09:58.825: %LINK-3-UPDOWN: Interface Port-channel1, changed state to up Apr 4 09:04:24 192.168.1.144 184: *Mar 15 17:09:59.722: %LINEPROTO-5- UPDOWN: Line protocol on Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:04:24 192.168.1.144 185: *Mar 15 17:09:59.832: %LINEPROTO-5- UPDOWN: Line protocol on Interface Port-channel1, changed state to up
As you can see, the ports go up and down many times (very strange, but maybe this is "by-design"). And it takes always 1 minute between LINK-3-UPDOWN and LINEPROTO-5-UPDOWN. The thing that makes me thinking of that this should be explainable: Why does it take always 1 minute? Is there something that can be configured which causes this delay? What does the switch expect? What does it wait for?
It's nice to get good input in this mailing list! Thanks for that! =)
Cheers, Tobias
-- Nine Internet Solutions AG, Albisriederstr. 243a, CH-8047 Zuerich Support +41 44 637 40 40 | Tel +41 44 637 40 00 | Direct +41 44 637 40 13 Skype nine.ch_support
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Mathias Seiler
MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99
mathias.seiler@mironet.ch
www.mironet.ch www.mirocloud.com
Sorry that was not 100% correct.
To disable LACP/PAGP negociation: Channel-group 1 mode on
As you are passing vlans you could just as well make sure all the interface are in trunk mode. So Switchport nonegociate will disable the dynamic trunk negociation.
Now you also mentioned "when I power up the Server" Is your server supporting LACP? How are is the bonding configured on the interfaces?
Eric
-----Message d'origine----- De : swinog-bounces@lists.swinog.ch [mailto:swinog- bounces@lists.swinog.ch] De la part de Eric Laporte Envoyé : mercredi 4 avril 2012 10:13 À : swinog@lists.swinog.ch Objet : Re: [swinog] EtherChannel - Long Time between LINK-3-UPDOWN and LINEPROTO-5-UPDOWN
Be aware of the port-channeling protocol you use ( LACP or PAGP ) Channel-group 1 mode active -> LACP
There are timers involved to get the port-channel up.
If you are sure about which interfaces will be part of it and you don't need to define spare ports Then you could also go for a static port-channel: switchport nonegociate
Also be careful to apply your vlans on the port-channel interface only. It gets replicated to the physical interfaces.
Eric
-----Message d'origine----- De : swinog-bounces@lists.swinog.ch [mailto:swinog- bounces@lists.swinog.ch] De la part de Tobias Brunner Envoyé : mercredi 4 avril 2012 09:12 À : swinog@lists.swinog.ch Objet : Re: [swinog] EtherChannel - Long Time between LINK-3-UPDOWN
and
LINEPROTO-5-UPDOWN
Hi all,
Thanks for the input so far. I've merged all the input of you (and the trunk/vlan configuration I need to use) and this is how the configuration looks right now:
interface GigabitEthernet1/0/1 switchport trunk encapsulation dot1q switchport trunk native vlan 27 switchport trunk allowed vlan 27,453 switchport mode trunk no cdp enable spanning-tree portfast trunk spanning-tree bpdufilter enable channel-group 1 mode active ! interface GigabitEthernet2/0/1 switchport trunk encapsulation dot1q switchport trunk native vlan 27 switchport trunk allowed vlan 27,453 switchport mode trunk no cdp enable spanning-tree portfast trunk spanning-tree bpdufilter enable channel-group 1 mode active ! interface Port-channel1 switchport trunk encapsulation dot1q switchport trunk native vlan 27 switchport trunk allowed vlan 27,453 switchport mode trunk spanning-tree portfast trunk spanning-tree bpdufilter enable end
It's not possible to just configure the "channel-group" on the GiX interfaces and all the rest on Po1 (as suggested by Steven), I had to add at
least
the "switchport" settings (otherwise the switch complains about not compatible ports). The addition of the spanning-tree settings to Po1 did not change the behaviour either. Also the used cables should be OK.
And now, when I power on the server, this is the output of the switch- log (The server boots from Network, then from local disk with Debian and
bonding
configured:
Apr 4 09:00:06 192.168.1.144 152: *Mar 15 17:05:41.781: %LINK-3-
UPDOWN:
Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:06 192.168.1.144 153: *Mar 15 17:05:41.781: %LINK-3-
UPDOWN:
Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:00:15 192.168.1.144 154: *Mar 15 17:05:51.202: %LINK-3-
UPDOWN:
Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:00:16 192.168.1.144 155: *Mar 15 17:05:52.250: %LINK-3-
UPDOWN:
Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:00:17 192.168.1.144 156: *Mar 15 17:05:53.525: %LINK-3-
UPDOWN:
Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:18 192.168.1.144 157: *Mar 15 17:05:54.607: %LINK-3-
UPDOWN:
Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:00:30 192.168.1.144 158: *Mar 15 17:06:05.907: %LINK-3-
UPDOWN:
Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:00:30 192.168.1.144 159: *Mar 15 17:06:05.924: %LINK-3-
UPDOWN:
Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:00:32 192.168.1.144 160: *Mar 15 17:06:08.465: %LINK-3-
UPDOWN:
Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:32 192.168.1.144 161: *Mar 15 17:06:08.482: %LINK-3-
UPDOWN:
Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:00:47 192.168.1.144 162: *Mar 15 17:06:22.701: %LINK-3-
UPDOWN:
Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:00:47 192.168.1.144 163: *Mar 15 17:06:22.718: %LINK-3-
UPDOWN:
Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:00:49 192.168.1.144 164: *Mar 15 17:06:25.050: %LINK-3-
UPDOWN:
Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:49 192.168.1.144 165: *Mar 15 17:06:25.285: %LINK-3-
UPDOWN:
Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:00:54 192.168.1.144 166: *Mar 15 17:06:29.957: %LINK-3-
UPDOWN:
Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:00:54 192.168.1.144 167: *Mar 15 17:06:30.116: %LINK-3-
UPDOWN:
Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:00:56 192.168.1.144 168: *Mar 15 17:06:32.515: %LINK-3-
UPDOWN:
Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:00:56 192.168.1.144 169: *Mar 15 17:06:32.641: %LINK-3-
UPDOWN:
Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:01:35 192.168.1.144 170: *Mar 15 17:07:10.768: %LINK-3-
UPDOWN:
Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:01:37 192.168.1.144 171: *Mar 15 17:07:13.125: %LINK-3-
UPDOWN:
Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:01:59 192.168.1.144 172: *Mar 15 17:07:35.430: %LINEPROTO-5- UPDOWN: Line protocol on Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:02:39 192.168.1.144 173: *Mar 15 17:08:15.142: %LINEPROTO-5- UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:02:56 192.168.1.144 174: *Mar 15 17:08:32.246: %LINEPROTO-5- UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:02:56 192.168.1.144 175: *Mar 15 17:08:33.253: %LINK-3-
UPDOWN:
Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:03:00 192.168.1.144 176: *Mar 15 17:08:35.753: %LINK-3-
UPDOWN:
Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:03:15 192.168.1.144 177: *Mar 15 17:08:51.649: %LINEPROTO-5- UPDOWN: Line protocol on Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:03:16 192.168.1.144 178: *Mar 15 17:08:52.446: %LINK-3-
UPDOWN:
Interface GigabitEthernet1/0/1, changed state to down Apr 4 09:03:16 192.168.1.144 179: *Mar 15 17:08:52.672: %LINK-3-
UPDOWN:
Interface GigabitEthernet2/0/1, changed state to down Apr 4 09:03:19 192.168.1.144 180: *Mar 15 17:08:54.979: %LINK-3-
UPDOWN:
Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:03:37 192.168.1.144 181: *Mar 15 17:09:13.308: %LINK-3-
UPDOWN:
Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:04:22 192.168.1.144 182: *Mar 15 17:09:57.835: %LINEPROTO-5- UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to up Apr 4 09:04:23 192.168.1.144 183: *Mar 15 17:09:58.825: %LINK-3-
UPDOWN:
Interface Port-channel1, changed state to up Apr 4 09:04:24 192.168.1.144 184: *Mar 15 17:09:59.722: %LINEPROTO-5- UPDOWN: Line protocol on Interface GigabitEthernet2/0/1, changed state to up Apr 4 09:04:24 192.168.1.144 185: *Mar 15 17:09:59.832: %LINEPROTO-5- UPDOWN: Line protocol on Interface Port-channel1, changed state to up
As you can see, the ports go up and down many times (very strange, but maybe this is "by-design"). And it takes always 1 minute between LINK-3-
UPDOWN
and LINEPROTO-5-UPDOWN. The thing that makes me thinking of that this
should
be explainable: Why does it take always 1 minute? Is there something that can be configured which causes this delay? What does the switch expect? What does it wait for?
It's nice to get good input in this mailing list! Thanks for that! =)
Cheers, Tobias
-- Nine Internet Solutions AG, Albisriederstr. 243a, CH-8047 Zuerich Support +41 44 637 40 40 | Tel +41 44 637 40 00 | Direct +41 44 637 40 13 Skype nine.ch_support
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Hi everyone,
I've "compiled" all your input, here is the output:
The cables are all cat5e, which should be OK. But to be sure I've managed to find a cat6 cable, but as expected, it did not change anything. So the cables are not the problem.
Then I added "speed 1000" and "duplex full" to the two port configuration, but: no change.
Next step: Try "mode on" -> Does not work because "on" is PAGP which is not compatible with LACP.
Go on: Try "switchport nonegotiate" -> No change in behaviour.
When the servers are booting (BIOS, not yet OS) then there is no bonding/etherchannel available. Both ports are independent. That should be no problem for the "mode active/passive" and it works as expected, the server can do DHCP/PXE during boot. But it takes a long time until the server gets an IP from DHCP because it takes so long to get the protocol up.
Is your server supporting LACP?
During BIOS boot: no While running OS: yes
How are is the bonding configured on the interfaces?
During BIOS boot: not configured While running OS: configured with linux bonding (that works fine)
Maybe this will stay a mysterium =)
I wish everyone good luck in finding the easter-eggs. (Maybe this behavior is a cisco-easter-egg and solved after easter, who knows =)
Cheers, Tobias
Tobias: Why is pxe enabled? Is this device having its IOS image downloaded from a tftp server every time it boots up? That would account for the latency... Vinnie
Connected by MOTOBLUR™
-----Original message----- From: Tobias Brunner tobias.brunner@nine.ch To: swinog@lists.swinog.ch Sent: Thu, Apr 5, 2012 16:21:26 GMT+02:00 Subject: Re: [swinog] EtherChannel - Long Time between LINK-3-UPDOWN and LINEPROTO-5-UPDOWN
Hi everyone,
I've "compiled" all your input, here is the output:
The cables are all cat5e, which should be OK. But to be sure I've managed to find a cat6 cable, but as expected, it did not change anything. So the cables are not the problem.
Then I added "speed 1000" and "duplex full" to the two port configuration, but: no change.
Next step: Try "mode on" -> Does not work because "on" is PAGP which is not compatible with LACP.
Go on: Try "switchport nonegotiate" -> No change in behaviour.
When the servers are booting (BIOS, not yet OS) then there is no bonding/etherchannel available. Both ports are independent. That should be no problem for the "mode active/passive" and it works as expected, the server can do DHCP/PXE during boot. But it takes a long time until the server gets an IP from DHCP because it takes so long to get the protocol up.
Is your server supporting LACP?
During BIOS boot: no While running OS: yes
How are is the bonding configured on the interfaces?
During BIOS boot: not configured While running OS: configured with linux bonding (that works fine)
Maybe this will stay a mysterium =)
I wish everyone good luck in finding the easter-eggs. (Maybe this behavior is a cisco-easter-egg and solved after easter, who knows =)
Cheers, Tobias
Hi,
Tobias: Why is pxe enabled? Is this device having its IOS image downloaded from a tftp server every time it boots up? That would account for the latency...
PXE is enabled on the server, not on the switch =)
Tobias
Hi Tobias
It may be a stupid question, but have you tried opening a SR with Cisco TAC ? :)
Cheers!
On 5 Apr 2012, at 17:41, Tobias Brunner wrote:
Hi,
Tobias: Why is pxe enabled? Is this device having its IOS image downloaded from a tftp server every time it boots up? That would account for the latency...
PXE is enabled on the server, not on the switch =)
Tobias
-- Nine Internet Solutions AG, Albisriederstr. 243a, CH-8047 Zuerich Support +41 44 637 40 40 | Tel +41 44 637 40 00 | Direct +41 44 637 40 13 Skype nine.ch_support
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Mathias Seiler
MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99
mathias.seiler@mironet.ch
www.mironet.ch www.mirocloud.com
Hi Tobias
Here are perhaps some hints...
-channel-group NUMBER mode on: Is a static channel with NO channel protocol on it. If you speak LACP on the other side the channel won't come up because the neighbors don't agree to a channel. You need a "channel-group NUMBER mode active" on the switch side so it speaks LACP. Set it to this mode and run a debug on the switch so you can see more: debug lacp ? See: (http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/1...) You can also fix the channel only to speak LACP with "channel-protocol lacp" in combination with "channel-group NUMBER active". See: (http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/1...)
-switchport nonegotiate: disables DTP (dynamic trunking protocol) which is used to negotiate a trunk between to dtp speaking switches. If you set the port to "switchport mode trunk" on the switch side then you make a trunk on this port. See: (http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/1...) . So in my point of view you don't need the "switchport nonegotiate" command.
-speed 1000: if you fix the speed to 1Gbit then its always full duplex. There is no 1Gbit with halfduplex as far as I know. So the duplex full is also useless on this port. Generally speaking: If you fix the duplex mode and speed one side please watch out that you also fix it on the other side.
So I would frist watch out that the channel comes up. For trunking and vlans on the trunks you can troubleshoot later.
Cheers
Luki
Am 05.04.2012 16:21, schrieb Tobias Brunner:
Hi everyone,
I've "compiled" all your input, here is the output:
The cables are all cat5e, which should be OK. But to be sure I've managed to find a cat6 cable, but as expected, it did not change anything. So the cables are not the problem.
Then I added "speed 1000" and "duplex full" to the two port configuration, but: no change.
Next step: Try "mode on" -> Does not work because "on" is PAGP which is not compatible with LACP.
Go on: Try "switchport nonegotiate" -> No change in behaviour.
When the servers are booting (BIOS, not yet OS) then there is no bonding/etherchannel available. Both ports are independent. That should be no problem for the "mode active/passive" and it works as expected, the server can do DHCP/PXE during boot. But it takes a long time until the server gets an IP from DHCP because it takes so long to get the protocol up.
Is your server supporting LACP?
During BIOS boot: no While running OS: yes
How are is the bonding configured on the interfaces?
During BIOS boot: not configured While running OS: configured with linux bonding (that works fine)
Maybe this will stay a mysterium =)
I wish everyone good luck in finding the easter-eggs. (Maybe this behavior is a cisco-easter-egg and solved after easter, who knows =)
Cheers, Tobias
-
Andreas Fink -
Eric Laporte -
Kurt Mathys (kmathys) -
Lukas Eisenberger -
Mathias Seiler -
Steven Glogger -
Tobias Brunner -
vwatson＠dancendrumarts.com