May 29, 2008 at 11:49 am #41041
I’m trying to configure a Zeroshell bridge to implement QoS on my LAN. I use VMware ESX server and so have configured everything as follows:
> Cisco PIX Firewall
> Zeroshell bridge VM
I followed the instructions on Zeroshell/QoS and all seemed to go as planned. Now though any machines on the LAN have very limited access to anything behind the Zeroshell VM. There is someconnectivity (for example I was able to get a DHCP request through) but no HTTP, SMTP, etc.
To test that the VLANs are working correctly I moved all of the machines into VLAN4 whereupon they can see the Internet and each other as expected. In VLAN3 they can see each other but not the Internet.
Any help would be appreciated.
GeorgeMay 29, 2008 at 1:16 pm #46522
Sorry, should have mentioned that I’m using the Zeroshell VMware applicance (ZeroShell-1.0.beta9-VMWARE.zip).May 29, 2008 at 5:18 pm #46523
Are you sure that VLAN3 and VLAN4 are necessary in your setup? the VLANS are 802.1q trunks? In this case post us more details about the subnets you use and how you create the bridge.
FulvioMay 29, 2008 at 5:49 pm #46524
Hi fulvio, thanks for the reply.
I put the VLANs in place to seperate the two parts of the network which the bridge then connects, providing the QoS. I will attempt to explain in more detail below.
Basically the servers, and the Zeroshell are all running on virtual machines in the same VMware ESX server. The servers and workstations are all on the Inside VLAN, the Zeroshell VM has two interfaces, one of which is on the Inside VLAN, the other on the same VLAN as the firewall.
All machines have addresses on the 192.168.11.0/24 network. The firewall is also on this range. My understanding was that the Zeroshell should act as a L2 bridge between the two segments, therefore forwarding all packets it receives on either interface and doing QoS according to the rules I have created. This doesn’t seem to be happening at the moment, although broadcasts must be getting through, because a test laptop I used managed to get an DHCP IP across the Zeroshell. If I didn’t use VLANs, then when the machines try to get to the default gateway (i.e. the firewall) then they will access it directly, therefore no QoS. Or is this incorrect?
To give an example, my test machine is 192.168.11.10, so the network map is like this:
192.168.11.10 192.168.11.252 192.168.11.254
GeorgeMay 29, 2008 at 5:51 pm #46525
Just to clarify, the Zeroshell machine doesn’t see the 802.1q trunks, it just has one interface in one segment (VLAN3) and one in another (VLAN4).May 29, 2008 at 6:26 pm #46526
I have thought more about this, and I am fairly sure that I will have to use a L3 (i.e. routed) setup. The reason for this is that I’m trying to use a VM as the bridge, this would be fine if:
– all of the traffic came from the same virtual switch as the Zeroshell VM AND
– I could enable promiscuous mode on the virtual switch port and virtual NIC of the Zeroshell VM
However some of the traffic comes from the physical LAN, hence same VLAN but seperate switch, and I think that promiscuous mode is disabled by default in VMware ESX.
What is required to change from a bridged to a routed configuration?
Thanks, GeorgeJune 9, 2008 at 10:32 pm #46527
Just to close off this topic, here’s a quick update.
I managed to get QoS working in my environment by changing from a bridged to routed configuration. I’m still not clear on why the bridged setup didn’t work, but by moving everything to layer 3 everything is working as expected.
What I did:
– Gave ETH00 and ETH01 IP addresses, on different IP networks/VLANs
– Changed inside IP of firewall to same IP subnet/VLAN as ETH01
– Gave ETH00 the firewall’s old inside IP
– Configured the default gw on Zeroshell to point to the inside IP of firewall
– Default gw of other machines on network were already pointing at Zeroshell, as ETH00 had the firewall’s old IP
After making these changes traffic flows and I can see the effect of shaping when I alter the QoS parameters.
Thanks for making such a useful product open-source. I love linux! 😀
You must be logged in to reply to this topic.