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]
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

Reply via email to