Thanks Michael, I'll admit I'm quite a newbie with this, but I'm doing
it self educate so I have an understanding of how this is expected to work.
To give you an idea of my goal as well as network topology, it consists
of this:
Shorewall box with two network cards, eth0 is on a Comcast Business
class modem with 5 public IP's. eth1 serves the local network and
(hopefully at some point) vlan2, and maybe a 3rd vlan in the future.
eth1 is cabled to port 24 on a Netgear GS724T-300 gigabit switch, which
to the best of my knowledge is setup as a trunk port.
Here's the output of /proc/net/vlan/config:
r...@bubastis:/etc/shorewall# cat /proc/net/vlan/config
VLAN Dev name | VLAN ID
Name-Type: VLAN_NAME_TYPE_PLUS_VID_NO_PAD
vlan2 | 2 | eth1
Trying to keep everything on one network card if it's possible.
Thanks,
Stephen
On 11/25/10 4:23 PM, Michael Weickel - iQom Business Services GmbH wrote:
Could you please send
cat /proc/net/vlan/config
Actually its very strange to me that you try to make subifs while
using the physical interface as well. This is normally not what needs
to be done. Either you go by layer-3 physical ip interface or you
consider it to be "null" (which obviously means to treat the interface
in a trunking mode) by having as many layer-3 vlan subifs as you like.
This configuration may causes your martian log or in other words
causes why your packet arrives on eth1 instead of vlan2 because your
vlan kernel may get confused by that configuration. On a tagged
interface there should be nothing but tagged packets. To have a mix of
tagged and untagged packets in one and the same routed interface is
maybe not what you want.
Try to use another physical interface or switch your local lan segment
to be e.g. vlan 3. If I got your right you have a 802.1q enabled
switch. So try to move your local network on that switch into access
vlan 3 and your voip network should already stay in access vlan 2.
This configuration should work as you expect it.
Let me now whats going on, we may figure it out. All what I can offer
to you is to reproduce each time on one of our machines with vlan
support enabled.
Cheers
Michael
------------------------------------------------------------------------
*Von:*Stephen Brown [mailto:[email protected]]
*Gesendet:* Donnerstag, 25. November 2010 21:26
*An:* Shorewall Users
*Betreff:* Re: [Shorewall-users] VLAN martians
Thanks Tom, here's the output of shorewall show routing:
Shorewall 4.4.11.6 Routing at bubastis - Thu Nov 25 15:22:40 EST 2010
Routing Rules
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
Table default:
Table local:
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
broadcast 10.5.10.255 dev vlan2 proto kernel scope link src 10.5.10.1
local 10.5.1.1 dev eth1 proto kernel scope host src 10.5.1.1
broadcast 10.5.1.0 dev eth1 proto kernel scope link src 10.5.1.1
local 70.90.228.197 dev eth0 proto kernel scope host src 70.90.228.197
broadcast 70.90.228.199 dev eth0 proto kernel scope link src
70.90.228.197
local 10.5.10.1 dev vlan2 proto kernel scope host src 10.5.10.1
local 70.90.228.193 dev eth0 proto kernel scope host src 70.90.228.197
broadcast 10.5.10.0 dev vlan2 proto kernel scope link src 10.5.10.1
broadcast 70.90.228.192 dev eth0 proto kernel scope link src
70.90.228.197
local 70.90.228.195 dev eth0 proto kernel scope host src 70.90.228.197
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
broadcast 10.5.1.255 dev eth1 proto kernel scope link src 10.5.1.1
local 70.90.228.194 dev eth0 proto kernel scope host src 70.90.228.197
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
Table main:
70.90.228.192/29 dev eth0 proto kernel scope link src 70.90.228.197
10.5.10.0/24 dev vlan2 proto kernel scope link src 10.5.10.1
10.5.1.0/24 dev eth1 proto kernel scope link src 10.5.1.1
default via 70.90.228.198 dev eth0
And this is a sample of what I see in the logs:
Nov 25 15:24:36 bubastis kernel: [28104.130146] martian source
10.5.1.1 from 10.5.10.2, on dev eth1
Nov 25 15:24:36 bubastis kernel: [28104.130152] ll header:
d8:5d:4c:b0:70:8e:00:25:90:01:35:44:08:00
I kinda think I know what's going on, but not really.
Any help appreciated :)
Thanks,
Stephen
On 11/25/10 2:24 PM, Tom Eastep wrote:
On 11/25/10 11:11 AM, Stephen Brown wrote:
I'm playing around with VLAN's and I have a VLAN capable (layer 2) smart
switch. I see a steady stream of martians in the logfile if I have the
routefilter option set on the loc zone interfaces in
/etc/shorewall/interfaces. I have two interfaces in the loc zone, eth1
and vlan2 respectively. vlan2 is an 802.1q trunk going towards the switch.
Is this the expected behavior in this configuration? I just want to make
sure Im not missing anything because I've seen some weird stuff happening.
Here's my /etc/shorewall/interfaces:
#ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect tcpflags,nosmurfs,routefilter,logmartians
loc eth1 detect dhcp,tcpflags,nosmurfs,logmartians
loc vlan2 detect dhcp,tcpflags,nosmurfs,logmartians
And /etc/network/interfaces:
# eth1 - local lan segment (gigabit)
auto eth1
iface eth1 inet static
address 10.5.1.1
netmask 255.255.255.0
# VLAN 2 - VoIP network
auto vlan2
iface vlan2 inet static
address 10.5.10.1
netmask 255.255.255.0
vlan_raw_device eth1
I just want to make sure my approach is right with this configuration...
my end goal is to contain my VoIP network in VLAN2. So far it works, but
still a few anomalies.....
Let's be clear -- Martians have nothing to do with Shorewall and
everything to do with routing. So ignore Shorewall for now and fix your
network configuration.
If you forward:
a) The output of 'shorewall show routing'; and
b) A copy of the martian messages that you are seeing
then we may be able to help.
-Tom
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App& Earn a Chance To Win $500!
Tap into the largest installed PC base& get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Shorewall-users mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/shorewall-users
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App& Earn a Chance To Win $500!
Tap into the largest installed PC base& get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
