Sorry I'm not the metro guy. I have a pfsense box plugged into a non-managed switch, so the vlan MTU had to be dropped to 1496. The pfsense box only sees traffic on the vlan when there's a tcpdump session running.
On the other box I had to disable rp_filter before the vlan tagging worked. I haven't found the same thing in freeBSD. This is what rp_filter does in linux. 546 rp_filter - BOOLEAN 547 1 - do source validation by reversed path, as specified in RFC1812 548 Recommended option for single homed hosts and stub network 549 routers. Could cause troubles for complicated (not loop free) 550 networks running a slow unreliable protocol (sort of RIP), 551 or using static routes. 552 553 0 - No source validation. 554 555 conf/all/rp_filter must also be set to TRUE to do source validation 556 on the interface 557 558 Default value is 0. Note that most distributions enable it in startup scripts. I imagine the same concept is hidden somewhere in sysctl but I can't spot it. These are possibilities... net.inet.ip.check_interface: 0 net.inet.ip.sourceroute: 0 net.inet.ip.redirect: 0 Or do I just "ifconfig vlan0 mtu 1496 promisc" ? -----Original Message----- From: Charles Sprickman [mailto:[EMAIL PROTECTED] Sent: Thursday, 9 November 2006 2:32 p.m. To: support@pfsense.com Subject: RE: [pfSense Support] VLAN trunking? On Thu, 9 Nov 2006, Craig FALCONER wrote: > Heya - not wishing to argue, but I'm really telling the truth. Here's kind of an out of left field idea... Someone mentioned that running tcpdump on a vlan interface actually *breaks* it. By "breaks", I'm betting that means "sends the vlan traffic without vlan tags". If that is indeed the case, perhaps your metro ether provider does not allow tagged ethernet packets. Make sense? Charles > vlan0 is 192.168.200.1/24 and the workstation is at 192.168.200.2 > > # ping 192.168.200.2 > PING 192.168.200.2 (192.168.200.2): 56 data bytes > 64 bytes from 192.168.200.2: icmp_seq=0 ttl=64 time=4.221 ms 64 bytes > from 192.168.200.2: icmp_seq=1 ttl=64 time=1.233 ms ^C > --- 192.168.200.2 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > round-trip min/avg/max/stddev = 1.233/2.727/4.221/1.494 ms > # ps auxw | grep tcpdump > root 298 0.0 0.9 3832 2172 d0- S Sat07PM 0:51.74 > /usr/sbin/tcpdump -l -n -e -ttt -i pflog0 > root 48512 0.0 0.2 1468 608 p0 R+ 2:15PM 0:00.01 grep tcpdump > root 67821 0.0 0.9 3852 2244 p0- S 9:12PM 0:17.03 tcpdump -i > vlan0 > # kill 67821 > # ping 192.168.200.2 > PING 192.168.200.2 (192.168.200.2): 56 data bytes > ^C > --- 192.168.200.2 ping statistics --- > 4 packets transmitted, 0 packets received, 100% packet loss > # tcpdump -i vlan0 > /dev/null & > [1] 48592 > # tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on vlan0, link-type EN10MB (Ethernet), capture size 96 bytes > # ping 192.168.200.2 > PING 192.168.200.2 (192.168.200.2): 56 data bytes > 64 bytes from 192.168.200.2: icmp_seq=0 ttl=64 time=2.412 ms > 64 bytes from 192.168.200.2: icmp_seq=1 ttl=64 time=1.009 ms > ^C > --- 192.168.200.2 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > round-trip min/avg/max/stddev = 1.009/1.710/2.412/0.701 ms > # > > > All I can think of is more Nokia weirdness. This is an IP330 with > three on-board NICs. > > > -----Original Message----- > From: Chris Buechler [mailto:[EMAIL PROTECTED] > > Bill Marquette wrote: >>> >>> Doesn't really make any sense. We already are doing a background >>> TCPDUMP to get the firewall logs. >> >> On pflog0. This is on the vlan interface which really is bizarre. I >> could see if for some reason the physical fxp interface wasn't in >> PROMISC mode needing to do it for that interface, but for the vlan >> interface I'm stumped. > > And he said that's the only way it *works*? Due to the FreeBSD + > promisc bug with VLAN's, tcpdumping any vlanX interface or the parent > interface should kill all network activity on all VLAN's. Does on > every box I've tried, and others have reported the same. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
