Upgraded to fedora 15, no outside network connectivity

ACiD GRiM · #1 17th June 2011, 09:22 PM

I have a relitively complex configuration for my dual NIC nonproduction server that uses lacp bonding, bridging, and vlans. It was working really well on Fedora 14, but when I upgraded to Fedora 15, I'm unable to ping any resource that is behind the NICs.

I unbonded one of the interfaces and removed the LACP channel from the interface on my switch hoping to find that there was just the bonding config, but I've found that I can't even network with a basic NIC config.

The interesting thing is that even with all of the bonds, bridges, and vlan interfaces set up, I can ping internal virtual machines just fine.

Any suggestions on how I can start to tackle this would be great!

stustustu · #2 18th June 2011, 05:21 AM

Is it a Dell machine?

kernel 2.6.38.8-32 has a fix for Dell systems where network adaptors weren't named correctly.

changelog:

Code:

* Sat May 07 2011 Chuck Ebbert <cebbert@redhat.com>
- Fix breakage of network device names on Dell systems (#702740)

Does this help?

ACiD GRiM · #3 18th June 2011, 09:40 AM

It's a super micro motherboard. I'm on kernel 2.6.38.6-27, but the problem is that I can't connect to the network to update. I'm pretty sure that native devices are being named eth0 and eth1 properly though

sonoran · #4 18th June 2011, 10:08 AM

Quote:

Originally Posted by ACiD GRiM

It's a super micro motherboard. I'm on kernel 2.6.38.6-27, but the problem is that I can't connect to the network to update. I'm pretty sure that native devices are being named eth0 and eth1 properly though

Fedora 15 uses biosdevname for consistent network device naming:

http://fedoraproject.org/wiki/Featur...rkDeviceNaming

eth0 et. al. are likely not called that anymore.

ACiD GRiM · #5 25th June 2011, 12:59 AM

Ok thank you for the suggestion, I reinstalled the entire OS hoping to just avert the entire issue. It's gotten better, but I am still having issues connecting. I'm guessing that now em1 and em2 are properly setup, the ethernet connection is being properly negotiated as my switch is no longer reporting an issue with that anymore.

I've found that I can connect to the network via the native vlan, but not via the vlan that I would like (vlan 2), so that's a sign there's a configuration issue somewhere.

Here's my Cisco 2960 config:

Code:

interface Port-channel1
description Zeus LACP
switchport mode trunk

interface GigabitEthernet1/0/3
 description Zeus LACP
 switchport mode trunk
 speed 1000
 duplex full
 channel-protocol lacp
 channel-group 1 mode active
!
interface GigabitEthernet1/0/4
 description Zeus LACP
 switchport mode trunk
 speed 1000
 duplex full
 channel-protocol lacp
 channel-group 1 mode active

And here's my network scripts

Code:

DEVICE=bond0
ONBOOT=yes
BRIDGE=br0
USERCTL=no
MTU=9000

DEVICE=bond0.10
VLAN=yes
BRIDGE=br0.10
USERCTL=no
MTU=9000

DEVICE=bond0.2
VLAN=yes
BRIDGE=br0.2
USERCTL=no
ONBOOT=yes
MTU=9000

DEVICE=bond0.20
VLAN=yes
BRIDGE=br0.20
USERCTL=no
MTU=9000

DEVICE=bond0.30
VLAN=yes
BRIDGE=br0.30
USERCTL=no
MTU=9000

DEVICE=br0
BOOTPROTO=none
ONBOOT=yes
TYPE=bridge
USERCTL=no
MTU=9000
IPADDR=10.0.0.2
PREFIX=23
BROADCAST=10.0.1.255

DEVICE=br0.10
#IPADDR=10.0.10.2
#PREFIX=24
#BROADCAST=10.0.10.255
BOOTPROTO=none
ONBOOT=yes
TYPE=bridge
USERCTL=no
MTU=9000

DEVICE=br0.2
IPADDR=10.0.2.124
PREFIX=24
BROADCAST=10.0.2.255
GATEWAY=10.0.2.1
DNS1=10.0.2.3
DNS2=8.8.8.8
BOOTPROTO=none
ONBOOT=yes
TYPE=bridge
USERCTL=no
MTU=9000

DEVICE=br0.20
#IPADDR=10.0.20.2
#PREFIX=24
#BROADCAST=10.0.20.255
BOOTPROTO=none
ONBOOT=yes
TYPE=bridge
USERCTL=no
MTU=9000

DEVICE=br0.30
#IPADDR=10.0.30.2
#PREFIX=24
#BROADCAST=10.0.30.255
BOOTPROTO=none
ONBOOT=yes
TYPE=bridge
USERCTL=no
MTU=9000

# Intel Corporation 82574L Gigabit Network Connection
DEVICE=em1
#ETHTOOL_OPTS="speed 1000 duplex full autoneg off"
BOOTPROTO=none
#HWADDR=00:25:90:01:A4:94
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
MTU=9000

# Intel Corporation 82574L Gigabit Network Connection
DEVICE=em2
#ETHTOOL_OPTS="speed 1000 duplex full autoneg off"
BOOTPROTO=none
#HWADDR=00:25:90:01:A4:95
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
MTU=9000

Raffaello22 · #6 25th June 2011, 09:18 AM

Hello,

Do you have 8021q module loaded ?

if not type:
modprobe 8021q

if it fail, check whether it has been compiled as module in your kernel
[root@unknown ~]# cat /boot/config-2.6.35.12-88.fc14.x86_64 | grep -i 8021q
CONFIG_VLAN_8021Q=m

If module is loaded, run sniffer and check if in frames from your fedora to Cisco is dot1q encapsulation header. It's another problem here, because a lot of network card stripping tags from frame before pcap libary capture packet, so better solution is checking tags on Cisco using debugging.

best regards,
Rafal

ACiD GRiM · #7 25th June 2011, 06:48 PM

It does appear that the 802.1q module is loaded, and I'm sure that the hardware interfaces aren't stripping the vlans because it worked previously. I'm starting to think that something in the software is stripping them, but I'm still not sure what. Do you think that maybe the bonding driver might be doing that?

Thanks for the help.

Raffaello22 · #8 25th June 2011, 07:54 PM

Quote:

Originally Posted by ACiD GRiM

It does appear that the 802.1q module is loaded, and I'm sure that the hardware interfaces aren't stripping the vlans because it worked previously. I'm starting to think that something in the software is stripping them, but I'm still not sure what. Do you think that maybe the bonding driver might be doing that?

Thanks for the help.

I mean that it can be problem only with sniffing packet (802.1q) not problem with 802.1q encapsulation.

As I wrote earlier type on Cisco (if your switch support this command)

Code:

 debug vlan packet

and this way debug whether the 802.1q header appears.

please also paste output following commands here:

Code:

show interface trunk

and

Code:

show spanning tree

best regards,
Rafal