Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
SDN 101: An Introduction to Software Defined Networking
Discover the advantages of SDN.
SDN has quickly become one of the hottest trends in IT. But not all SDN solutions offer real software-defined functionality. As more enterprises consider SDN, they want to know, “What is SDN? And what are the real benefits?” If you're ready to explore the advantages of SDN, and want to know how it should be implemented within your enterprise, start by reading our introductory white paper.
Click Here to receive this Complete Guide absolutely free.
I have a transparent firewalling bridge between two VLANs on Cisco switches. I had STP disabled, but now after over a year I wanted to enable it, so I did. I have eth0 and eth1 connected each to a different VLAN and on different Cisco switches, and eth0 and eth1 are bridged as "br0". However, I also have ebtables running on the bridge - and my rules are as follows (from my init.d script):
# set up packet filtering on the bridge to only allow ARP and IPv4 Ethernet packets
# note ebtables is the bridging at layer 2 (Ethernet, below TCP/IP)
echo "Starting ebtables firewalling..."
$EBTABLES -t filter -P FORWARD DROP #default to drop all not explicitly allowed
$EBTABLES -t filter -A FORWARD -p ARP -j ACCEPT #allow ARP (resolve ip addresses to mac addresses)
$EBTABLES -t filter -A FORWARD -p IPv4 -j ACCEPT #allow TCP/IP
$EBTABLES -t filter -A FORWARD -j DROP #deny everything else
Note that ebtables defaults to ACCEPT for its INPUT and OUTPUT chain.
My question is: Is there anything in the STP protocol that requires it to it be forwarded through the bridge, as my rules would block that, rather than just sent and received on the two NICs? Best I can tell by packet sniffing the STP protocol on my workstations, STP is only sent from a mac address specific to the port on the Cisco switch and sent to a special STP mac address.
Right, but the problem is without STP on the Linux bridge and with it blocking STP traffic, it seems to me if you would connect a crossover cable between the two VLANs somewhere else you could still generate the broadcast storm and take down my network.
i must say i don't really understand what use is your bridge, or your vlans...
one configures vlans to isolate 2 network segments, so that you don't get polluted by broadcasts, traffic that's definitly not for you etc...
so, what you wouldn't want, would be having a layer 2 link in-between your 2 vlans... you'll loose your isolation!! vlan interconnection should be done (and is done) at layer 3.
usually, you manage as well to set up two different IP networks for two vlans (vlan 100: 192.168.100.0/24, vlan 102: 192.168.102.0/24), this way you use a router to route packets between the 2 vlans.
but even if your 2 vlans use the same IP network, you have to go to layer 3:
Say a packet comes in eth0 from vlan 100.
It's ethernet header includes a field saying "I'm in vlan 100"
It comes into eth0, the ethernet header is removed so as to check the packet content.
According to the dest IP, you have to forward it
It goes to eth1 output queue
Since eth1 is in vlan 101, the ethernet header will include this info.
Note that Cisco switches are nice, if the packet is not tagged (no vlan info in the ethernet header), then if the interface of the switch is in a non-native vlan and is not a trunk, it will add the vlan tag for you (would be the case if you didn't configured vlans on your Linux box).
Note 2: Cisco switches are not nice towards packets that are not in the correct vlan. A packet that is tagged as vlan 100 and comes into a port of a cisco switch configured as vlan 101 will be dropped...
So, as your bridge is in fact working at layer 3 (even if it routes from a lan into the same lan) it shouldn't be part of STP.
The only setup I can see in which it would be better to activate STP is if your vlan 100 and vlan 101 spread accross the bridge (you have machines in both vlans on both interface of the bridge). In this case, to be compliant with Cisco and with the spaning tree protocol, you must have an instance of spanning tree per vlan, which means creating vlans in your Linux box (eth0.100 and eth1.100 in vlan 100, eth0.101 and eth1.101 in vlan 101), and then creating 2 bridges (br100 with eth0.100 and eth1.100; br101 with eth0.101 and eth1.101). Be cafrefull, you must use the same vlan numbers as in the ciscos, as this number is written in the ethernet frames. Take care as well of the native vlan used by cisco: the vlan 1 is called native by Cisco boxes, which means that ethernet frames are not tagged (whereas I believe Linux would tag the frames of vlan 1... I'm not sure about this one, it should be checked.... I think there must be a way to configure native vlan on Linux boxes as well).
Looks like BPDUs go from switch to switch and do not need to be forwarded.
Anyway, I'll explain why I am bridging two vlans at layer 2 and not layer 3. We had a subnet (192.168.0.0/24) with many PCs and many other devices on it. We wanted to add some extra security to who/what can access these devices as they are mission critical and don't have much security built into them. Switching them to their own subnet and routing to them would be an ideal solution, however ip addresses weren't allocated in a way that would make it easy to split the subnet and changing the ip address on many of them requires expensive downtime (things run continuously) and requires reconfiguration via a serial port connection (timeconsuming to go around to each one).
So the easier thing to do was to leave the PCs on VLAN 101, make a new vlan 102, then switch the network ports the devices were plugged into to vlan 102. Then you could connect a Cisco port set to vlan 101 and one set to vlan 102 with a crossover cable and everything would work - conceptually similar to having two separate unmanaged switches - one with all the PCs plugged into it, and one with all the devices plugged into it - and then connecting the two separate switches with a crossover cable. I then replace the crossover cable with the Linux bridge and use ebtables, the bridge-nf patch, and iptables to control what ethernet and ipv4 traffic can cross the bridge. I can drop broadcasts from going through it with iptables rules, and the Linux bridge does not even need to know about the vlans - there are no vlan tag in the ethernet headers of packets passing through it.
Its worked great so far, until last week a hardware or electrical problem on one of the Cisco switches or a device connected to it caused the switch to send vlan 101 traffic on vlan 102 and I did not have STP enabled on the Linux bridge, so the loop caused address flaps on other switches which took down some of my network for a couple minutes. So I enabled STP on the bridge, but wasn't sure if I'd need ebtables rules to allow it.