Hi, having VLAN support over VNICs is something that has to be implemented. Robert Mustacchi of Joyent knows more details. He also pointed out some guy to what has to be some time ago:
https://www.listbox.com/member/archive/184463/2015/08/search/dmxhbg/sort/time_rev/page/1/entry/3:20/20150828132325:7B361E98-4DA9-11E5-9563-A40B7DC7297B/ Cheers, Adam > On Mar 22, 2016, at 1:10 AM, Dave Finster <[email protected]> wrote: > > At this stage, no. I probably should have been clearer - the VLAN tagging > (adding and removing the tag to provide a pseudo access port) occurs at the > VNIC level AFAIK, so the restriction applies to both OS zones and KVMs. This > is because KVMs are simply a QEMU process running inside an OS zone so the > same VNIC construct is used. > > You might notice that I’m on that email thread under my old work email > address. > > - Dave > >> On 22 Mar 2016, at 10:03 AM, James Blachly <[email protected] >> <mailto:[email protected]>> wrote: >> >> Can a native OS zone manipulate the frames to add/remove VNIC tags? >> >> i.e., if a KVM virtualized router is not possible, can an OS zone be set up >> in its stead? >> >> Interestingly also because of this post I searched the mailinglist archives >> and found this post that indicates it may have been possible in past >> versions of SmartOS with KVM zones: >> https://www.mail-archive.com/smartos-discuss@lists.smartos.org.email.enqueue.archive.listbox.com/msg01152.html >> >> <https://www.mail-archive.com/smartos-discuss@lists.smartos.org.email.enqueue.archive.listbox.com/msg01152.html> >> >> >> James >> >>> On Mar 21, 2016, at 7:15 PM, Dave Finster <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi >>> >>> Adam is correct. vnics are treated as ‘access’ ports only so it is not >>> possible to add VLAN tags from within KVM - it has handled exclusively by >>> the vnic. >>> >>> Additionally, even if a VM is provided with allow_promisc so that it can >>> see all traffic, it will see all packets on the physical nic but with the >>> VLAN tags removed. >>> >>> - Dave >>> >>>> On 21 Mar 2016, at 11:31 PM, Adam Števko <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hi, >>>> >>>> just a hint that you can also use “snoop” on SmartOS to sniff KVM traffic >>>> from the hypervisor thanks to VND. The usage is as follows: >>>> >>>> snoop -rd netX -z <uuid> >>>> >>>> With this you can also check what really comes out of the KVM zone VNIC. >>>> >>>> Now for your problem, I don’t think that it is possible to add VLAN tag >>>> from inside the KVM. I suppose that the packet should be dropped. If I am >>>> mistaken, please somebody correct me. >>>> >>>> Cheers, >>>> Adam >>>> >>>>> On Mar 21, 2016, at 2:15 PM, Christopher J. Ruwe <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> at the moment I am trying to debug an issue with a KVM-virtualized >>>>> firewall appliance (pfsense) and think I need some help. >>>>> >>>>> Currently, I am trying to replace my vendor-supplied and otherwise >>>>> crappy DSL router (used as modem with pppoe) with a DSL modem >>>>> (smaller, more energy efficient, can do IPv6, which the router cannot, >>>>> ...). >>>>> >>>>> Upstream traffic over DLS arrives VLAN-tagged (VLAN 10). The router >>>>> which I want to replace removes the VLAN tag, so that I do not need to >>>>> do anything on the SmartOS hypervisor or the VM. >>>>> >>>>> The modem can only pass-through the VLAN-tagged ethernet frames. On my >>>>> notebook (Debian testing), connections with pppoe are straight-forward >>>>> to setup, I create a vNIC on eth0 tagged with VLAN 10 and dial up with >>>>> pppoe. >>>>> >>>>> I tried to reproduce this known-to-work setup on a KVM-virtualized >>>>> Debian8 (2f56d126-20d0-11e5-9e5b-5f3ef6688aba, debian-8, 20150702) >>>>> before moving on to pfsense - doesn't work there either and pfsense is >>>>> not very nice to debug ...) >>>>> >>>>> The NIC I give to this machine is defined as >>>>> >>>>> { >>>>> "nic_tag": "external", >>>>> "model": "e1000", >>>>> "ip": "dhcp", >>>>> "vlan_id": 10, >>>>> "allow_dhcp_spoofing": true, >>>>> "allow_ip_spoofing": true, >>>>> "allow_mac_spoofing": true, >>>>> "allow_restricted_traffic": true >>>>> } >>>>> >>>>> A successful ppoe transaction on my notebook (sudo tcpdump -i eth0 -Uw >>>>> | sudo tcpdump -en -r - vlan 10) looks like this: >>>>> >>>>> 12:46:46. 754960 50:7b:9d:30:56:13 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q >>>>> (0x8100), length 36: vlan 10, p 0, ethertype PPPoE D, PPPoE PADI >>>>> [Service-Name] [Host-Uniq 0x5E540000] >>>>> 540062 00:90:1a:a2:b4:c3 > 32:98:e8:57:94:13, ethertype 802.1Q >>>>> (0x8100), length 122: vlan 10, p 1, ethertype PPPoE S, PPPoE [ses >>>>> 0x2e78] IP6 (0x0057), length 98: fe80::90:1a00:242:9bfe > ff02::1: >>>>> ICMP6, router advertisement, length 56 >>>>> 084319 00:90:1a:a2:b4:c3 > 32:98:e8:57:94:13, ethertype 802.1Q >>>>> (0x8100), length 472: vlan 10, p 1, ethertype PPPoE S, PPPoE [ses >>>>> 0x2e78] IP (0x0021), length 448: 209.126.117.224.5078 > >>>>> 5061: UDP, length 418 >>>>> 274281 50:7b:9d:30:56:13 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q >>>>> (0x8100), length 36: vlan 10, p 0, ethertype PPPoE D, PPPoE PADI >>>>> [Service-Name] [Host-Uniq 0x06550000] >>>>> 279840 00:90:1a:a2:b4:c3 > 50:7b:9d:30:56:13, ethertype 802.1Q >>>>> (0x8100), length 66: vlan 10, p 1, ethertype PPPoE D, PPPoE PADO [AC- >>>>> Name "<...>"] [Host-Uniq 0x06550000] [Service-Name] [AC-Cookie <...>] >>>>> >>>>> [...] >>>>> >>>>> On the KVM-virtualized machine, the transaction never completes: >>>>> >>>>> 11:22:00. 733654 72:f2:50:ec:8d:b7 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q >>>>> (0x8100), length 36: vlan 10, p 0, ethertype PPPoE D, PPPoE PADI >>>>> [Service-Name] [Host-Uniq 0x31070000] >>>>> 739185 72:f2:50:ec:8d:b7 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q >>>>> (0x8100), length 36: vlan 10, p 0, ethertype PPPoE D, PPPoE PADI >>>>> [Service-Name] [Host-Uniq 0x31070000] >>>>> >>>>> [...] >>>>> >>>>> Putting the modem on a switch allows me to watch what the KVM-machine >>>>> sends and recieves using the same tcpdump pattern. In addition, I can >>>>> (pppoe discovery uses broadcast) watch the KVM-machine sending from my >>>>> notebook. >>>>> >>>>> pppoe discovery leaves the KVM machine on the proper VLAN 10 and is >>>>> visible only on VLAN 10 on my notebook. I suspect this can be >>>>> generalized so that the modem is actually reached. >>>>> >>>>> No pppoe discovery replies reaches the KVM machine. I suspect the modem >>>>> replies to the pppoe discovery also for the KVM machines request as it >>>>> does for my notebook, but I do not know how to prove it. >>>>> >>>>> I am not too good with the tools available on a Solaris, I tried snoop >>>>> (snoop -d igb1 | grep -i pppoe) >>>>> >>>>> ? -> (broadcast) PPPoE PADI >>>>> ? -> (broadcast) PPPoE PADI >>>>> ? -> (broadcast) PPPoE PADI >>>>> VLAN#10: ? -> (broadcast) PPPoE PADI >>>>> VLAN#10: ? -> * PPPoE PADO >>>>> >>>>> which I interpret as the host seeing the discovery packets sent by the >>>>> host (PADI) and the answer (PADO). I am not sure however. >>>>> >>>>> I would interpret my attempts to observe the network traffic, so that >>>>> VLAN tagged traffic leaves and reaches the host but is not properly >>>>> passed on to the KVM-guest. >>>>> >>>>> Does anybody either ( would be best :-) ) how to properly connect KVM >>>>> guest to VLAN-tagged networks or would know how to debug that issue >>>>> better than I just tried? >>>>> >>>>> In any case, thanks and cheers, >>>>> -- >>>>> Christopher >>>>> >>>> >>>> >> > > smartos-discuss | Archives > <https://www.listbox.com/member/archive/184463/=now> > <https://www.listbox.com/member/archive/rss/184463/27758409-23ef20b1> | > Modify <https://www.listbox.com/member/?&;> Your Subscription > <http://www.listbox.com/>
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
