Bug 163803 - vlan does not work
Summary: vlan does not work
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 9.0-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-net (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-03 22:00 UTC by kes-kes
Modified: 2018-05-28 19:49 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description kes-kes 2012-01-03 22:00:21 UTC
as you can see on vlan408 there is arp reply messages from localhost
but on igb0 there is arp replay traffic.

Fix: 

Does that related to save energy subsystem of LAN card? (it turns off,
but do not turn on something)
How-To-Repeat: on the switch turn off port where igb0 is connected, reboot system,
leave system in this state for two days, after two days trun on port:

# ifconfig igb0
igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=1bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4>
        ether 00:1b:21:45:da:b8
        inet6 fe80::21b:21ff:fe45:dab8%igb0 prefixlen 64 scopeid 0x1
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
# ifconfig vlan408
vlan408: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=3<RXCSUM,TXCSUM>
        ether 00:1b:21:45:da:b8
        inet 10.11.19.54 netmask 0xfffffff8 broadcast 10.11.19.55
        inet6 fe80::21b:21ff:fe45:dab8%vlan408 prefixlen 64 scopeid 0x23
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        vlan: 408 parent interface: igb0
on one console:
# tcpdump -n -i vlan408
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan408, link-type EN10MB (Ethernet), capture size 65535 bytes
23:26:55.636979 ARP, Request who-has 10.11.19.54 tell 10.11.19.53, length 46
23:26:55.636996 ARP, Reply 10.11.19.54 is-at 00:1b:21:45:da:b8, length 28
23:26:56.842635 ARP, Request who-has 10.11.19.51 tell 10.11.19.52, length 42
23:26:57.841024 ARP, Request who-has 10.11.19.51 tell 10.11.19.52, length 42
23:26:58.616629 IP 10.11.19.54.42483 > 10.11.19.53.22: Flags [S], seq 1536743224, win 8192, options [mss 1460,sackOK,eol], length 0
23:26:58.841133 ARP, Request who-has 10.11.19.51 tell 10.11.19.52, length 42
23:26:59.309114 ARP, Request who-has 10.11.19.50 tell 10.11.19.54, length 28
23:27:00.558856 ARP, Request who-has 10.11.19.50 tell 10.11.19.52, length 42
23:27:00.700957 IP 10.11.19.54.53179 > 10.11.19.53.22: Flags [S], seq 1698787765, win 8192, options [mss 1460,nop,wscale 9,sackOK,TS val 1581662728 ecr 0], length 0

on other console:
# tcpdump -n -i igb0 -XXX
23:26:55.636975 ARP, Request who-has 10.11.19.54 tell 10.11.19.53, length 46
        0x0000:  ffff ffff ffff 0030 679d 8f26 8100 0198  .......0g..&....
        0x0010:  0806 0001 0800 0604 0001 0030 679d 8f26  ...........0g..&
        0x0020:  0a0b 1335 0000 0000 0000 0a0b 1336 0000  ...5.........6..
        0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
23:26:56.842630 ARP, Request who-has 10.11.19.51 tell 10.11.19.52, length 42
        0x0000:  ffff ffff ffff 0006 4f76 9695 8100 0198  ........Ov......
        0x0010:  0806 0001 0800 0604 0001 0006 4f76 9695  ............Ov..
        0x0020:  0a0b 1334 0000 0000 0000 0a0b 1333 0000  ...4.........3..
        0x0030:  0000 0000 0000 0000 0000 0000            ............
23:26:57.841018 ARP, Request who-has 10.11.19.51 tell 10.11.19.52, length 42
        0x0000:  ffff ffff ffff 0006 4f76 9695 8100 0198  ........Ov......
        0x0010:  0806 0001 0800 0604 0001 0006 4f76 9695  ............Ov..
        0x0020:  0a0b 1334 0000 0000 0000 0a0b 1333 0000  ...4.........3..
        0x0030:  0000 0000 0000 0000 0000 0000            ............
23:26:58.841126 ARP, Request who-has 10.11.19.51 tell 10.11.19.52, length 42
        0x0000:  ffff ffff ffff 0006 4f76 9695 8100 0198  ........Ov......
        0x0010:  0806 0001 0800 0604 0001 0006 4f76 9695  ............Ov..
        0x0020:  0a0b 1334 0000 0000 0000 0a0b 1333 0000  ...4.........3..
        0x0030:  0000 0000 0000 0000 0000 0000            ............
23:27:00.558844 ARP, Request who-has 10.11.19.50 tell 10.11.19.52, length 42
        0x0000:  ffff ffff ffff 0006 4f76 9695 8100 0198  ........Ov......
        0x0010:  0806 0001 0800 0604 0001 0006 4f76 9695  ............Ov..
        0x0020:  0a0b 1334 0000 0000 0000 0a0b 1332 0000  ...4.........2..
        0x0030:  0000 0000 0000 0000 0000 0000            ............

reboot system
after reboot traffice flows in normal way.
Comment 1 Gleb Smirnoff freebsd_committer freebsd_triage 2012-01-04 12:07:50 UTC
On Tue, Jan 03, 2012 at 09:52:50PM +0000, Eugen Konkov wrote:
E> FreeBSD  9.0-CURRENT FreeBSD 9.0-CURRENT #1: Wed Dec 28 15:40:29 EET 2011     @:/usr/obj/usr/src/sys/KES_KERN_v9  i386

What FreeBSD version are you running? As of Dec 28 2011, the 9 branch stored
in stable/9 svn branch should be named 9.0-PRERELEASE, and the head/ branch
is named 10.0-CURRENT.

The perfect answer would be name of svn branch and revision are you
running. However, CVS tag and date would also work.

-- 
Totus tuus, Glebius.
Comment 2 Garrett Cooper 2012-08-17 21:12:26 UTC
I'm seeing similar behavior on 9.0-RELEASE as well...

wf048# tcpdump -n -i cxgb1.190 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on cxgb1.190, link-type EN10MB (Ethernet), capture size 65535 bytes
20:10:04.622312 ARP, Reply 10.7.190.126 is-at 14:fe:b5:d0:c8:25, length 46
20:10:04.804766 ARP, Reply 10.7.190.132 is-at 14:fe:b5:d1:80:39, length 46
20:10:05.791876 ARP, Request who-has 10.52.0.3 tell 10.52.190.15, length 46
20:10:06.791970 ARP, Request who-has 10.52.0.3 tell 10.52.190.15, length 46
20:10:07.791939 ARP, Request who-has 10.52.0.3 tell 10.52.190.15, length 46
20:10:09.797397 ARP, Reply 10.7.190.187 is-at 84:2b:2b:6d:32:d6, length 46
20:10:10.792135 ARP, Request who-has 10.52.0.3 tell 10.52.190.15, length 46
20:10:11.768708 ARP, Request who-has 10.7.190.26 tell 10.7.190.210, length 46
20:10:11.792195 ARP, Request who-has 10.52.0.3 tell 10.52.190.15, length 46
20:10:12.792233 ARP, Request who-has 10.52.0.3 tell 10.52.190.15, length 46
20:10:13.984306 ARP, Request who-has 10.7.190.241 tell 10.7.190.1, length 46
20:10:14.275655 ARP, Reply 192.168.0.120 is-at 14:fe:b5:da:e2:07, length 46
20:10:15.792415 ARP, Request who-has 10.52.0.3 tell 10.52.190.15, length 46
^C
13 packets captured
56 packets received by filter
0 packets dropped by kernel
wf048# uname -a
FreeBSD wf048.west.isilon.com 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue
Jan  3 07:46:30 UTC 2012
root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

... but not 7.4-RELEASE...

# tcpdump -n -i cxgb0.190 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on cxgb0.190, link-type EN10MB (Ethernet), capture size 96 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Is vlan traffic broken on 9.x+? I need to do more digging in
9.1-PRERELEASE/10-CURRENT.

Thanks!
-Garrett
Comment 3 karl 2014-03-20 16:22:36 UTC
Hi,

I stumbled across this PR the other day - having a similar issue setting up 
VLANs under 10.x in this case.

After much head scratching I found, for example on a freshly installed, run 
up FBSD 10.x box:

ifconfig bge1.100 create
ifconfig bge1.100 192.168.0.20 netmask 255.255.255.0

[and equivalent on the other side]

Doesn't work - you see ARP requests flying around - but no traffic is 
exchanged.

However, doing:

ifconfig bge1 up

(i.e. Bringing up the 'parent' / underlying NIC on both machines)

After a few seconds - everything 'works', and traffic does flow over the 
VLAN (i.e. ARP requests are answered etc.)

Whether this is the same issue, whether it's a "bug" that the interface 
isn't brought 'up' when the vlan virtual interface is created - who knows.

Similar thing happens for LAGG interfaces - unless you have a dummy:

  ifconfig_bge1="UP"

In /etc/rc.conf - LAGG configs don't work either.

Anyway, just thought I'd post a followup to this - incase this 'fixes' (or 
at least sheds light) on the original issue.

-Karl
Comment 4 Hiren Panchasara freebsd_committer freebsd_triage 2017-01-07 23:59:54 UTC
(In reply to karl from comment #3)
I think this is intended behavior but I'd let someone from the list confirm and close the bug in that case. If not, someone needs to test -CURRENT or 11 for this bug.
Comment 5 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:49:57 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.