Hi, thanks for your help so far. I (almost) have it and I think the SmartOS-stack is working as expected.
After your explanation that VLAN tags are stripped at the VNIC, it was easy to make a "VLAN-tagged VNIC" assocoiated with my debugging KVM- guest. I verified VLAN connectivity by pinging from a host on my network with an IP-range exclusive to VLAN 10, ICMP packets came through visible by ping, tcpdump and snoop. It now very much appears that the problem is with my upstream provider. From the logs: Mar 22 11:38:14 localhost pppd[1807]: pppd 2.4.6 started by root, uid 0 Mar 22 11:38:14 localhost pppd[1807]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12 Mar 22 11:38:14 localhost pppd[1807]: dst ff:ff:ff:ff:ff:ff src f2:3c:83:89:3e:a3 Mar 22 11:38:14 localhost pppd[1807]: [service-name] [host-uniq 0f 07 00 00] Mar 22 11:38:19 localhost pppd[1807]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12 Mar 22 11:38:19 localhost pppd[1807]: dst ff:ff:ff:ff:ff:ff src f2:3c:83:89:3e:a3 Mar 22 11:38:19 localhost pppd[1807]: [service-name] [host-uniq 0f 07 00 00] Mar 22 11:38:19 localhost pppd[1807]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 42 Mar 22 11:38:19 localhost pppd[1807]: dst f2:3c:83:89:3e:a3 src 00:90:3e:a3:00:90 Mar 22 11:38:19 localhost pppd[1807]: [AC-name netdsl] [host-uniq 0f 07 00 00] [service-name] [AC-cookie 62 59 37 27 da cb 0e 6d 8c d3 af 7e 48 68 aa 09] Mar 22 11:38:19 localhost pppd[1807]: Send PPPOE Discovery V1T1 PADR session 0x0 length 32 Mar 22 11:38:19 localhost pppd[1807]: dst 00:90:3e:a3:00:90 src f2:3c:83:89:3e:a3 Mar 22 11:38:19 localhost pppd[1807]: [service-name] [host-uniq 0f 07 00 00] [AC-cookie 62 59 37 27 da cb 0e 6d 8c d3 af 7e 48 68 aa 09] Mar 22 11:38:24 localhost pppd[1807]: Send PPPOE Discovery V1T1 PADR session 0x0 length 32 Mar 22 11:38:24 localhost pppd[1807]: dst 00:90:3e:a3:00:90 src f2:3c:83:89:3e:a3 Mar 22 11:38:24 localhost pppd[1807]: [service-name] [host-uniq 0f 07 00 00] [AC-cookie 62 59 37 27 da cb 0e 6d 8c d3 af 7e 48 68 aa 09] Mar 22 11:38:34 localhost pppd[1807]: Send PPPOE Discovery V1T1 PADR session 0x0 length 32 Mar 22 11:38:34 localhost pppd[1807]: dst 00:90:3e:a3:00:90 src f2:3c:83:89:3e:a3 Mar 22 11:38:34 localhost pppd[1807]: [service-name] [host-uniq 0f 07 00 00] [AC-cookie 62 59 37 27 da cb 0e 6d 8c d3 af 7e 48 68 aa 09] Mar 22 11:38:54 localhost pppd[1807]: Timeout waiting for PADS packets Mar 22 11:38:54 localhost pppd[1807]: Unable to complete PPPoE Discovery Mar 22 11:39:05 localhost pppd[1807]: Terminating on signal 15 The situation has improved insofar that on PADI request I now recieve PADO answers. (I left ac-name and ac-cookie intact, hoping I do not open a security hole.) This behaviour is apparently named "tunnel-collapse", wich is obviously loosely associated with provider countermeasures against abuse. Various suggestions pointed me at changing the MAC address, which I did on the guest as I had mac-spoofing permitted anyhow. After changing, I got an unsuccessful auth transaction, from which I post only the relevant extract: Mar 22 12:07:43 localhost pppd[1866]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12 Mar 22 12:07:43 localhost pppd[1866]: dst ff:ff:ff:ff:ff:ff src 50:7b:9d:30:56:14 Mar 22 12:07:43 localhost pppd[1866]: [service-name] [host-uniq 4a 07 00 00] Mar 22 12:07:43 localhost pppd[1866]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 42 Mar 22 12:07:43 localhost pppd[1866]: dst 50:7b:9d:30:56:14 src 00:90:1a:a2:b4:c3 Mar 22 12:07:43 localhost pppd[1866]: [AC-name netdsl] [host-uniq 4a 07 00 00] [service-name] [AC-cookie b4 de ea bf ca bb 98 4a 2f bf 08 06 92 8b 28 e1] Mar 22 12:07:43 localhost pppd[1866]: Send PPPOE Discovery V1T1 PADR session 0x0 length 32 Mar 22 12:07:43 localhost pppd[1866]: dst 00:90:1a:a2:b4:c3 src 50:7b:9d:30:56:14 Mar 22 12:07:43 localhost pppd[1866]: [service-name] [host-uniq 4a 07 00 00] [AC-cookie b4 de ea bf ca bb 98 4a 2f bf 08 06 92 8b 28 e1] Mar 22 12:07:43 localhost pppd[1866]: Recv PPPOE Discovery V1T1 PADS session 0xe35 length 12 Mar 22 12:07:43 localhost pppd[1866]: dst 50:7b:9d:30:56:14 src 00:90:1a:a2:b4:c3 Mar 22 12:07:43 localhost pppd[1866]: [service-name] [host-uniq 4a 07 00 00] Mar 22 12:07:43 localhost pppd[1866]: PADS: Service-Name: '' Mar 22 12:07:43 localhost pppd[1866]: PPP session is 3637 Mar 22 12:07:43 localhost pppd[1866]: Connected to 00:90:1a:a2:b4:c3 via interface eth1 Mar 22 12:07:43 localhost pppd[1866]: using channel 3 Mar 22 12:07:43 localhost pppd[1866]: Using interface ppp0 Mar 22 12:07:43 localhost pppd[1866]: Connect: ppp0 <--> eth1 Mar 22 12:07:43 localhost pppd[1866]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0xeec843c6>] Mar 22 12:07:43 localhost pppd[1866]: rcvd [LCP ConfReq id=0xc0 <mru 1492> <auth pap> <magic 0x227972db>] Mar 22 12:07:43 localhost pppd[1866]: sent [LCP ConfAck id=0xc0 <mru 1492> <auth pap> <magic 0x227972db>] Mar 22 12:07:43 localhost pppd[1866]: rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0xeec843c6>] Mar 22 12:07:43 localhost pppd[1866]: sent [LCP EchoReq id=0x0 magic=0xeec843c6] Mar 22 12:07:43 localhost pppd[1866]: sent [PAP AuthReq id=0x1 user="<u name>" password=<hidden>] Mar 22 12:07:43 localhost pppd[1866]: rcvd [LCP EchoRep id=0x0 magic=0x227972db] Mar 22 12:07:43 localhost pppd[1866]: rcvd [PAP AuthNak id=0x1 "Request Denied"] Mar 22 12:07:43 localhost pppd[1866]: Remote message: Request Denied Mar 22 12:07:43 localhost pppd[1866]: PAP authentication failed Mar 22 12:07:43 localhost pppd[1866]: sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"] Mar 22 12:07:43 localhost pppd[1866]: rcvd [LCP TermReq id=0xc1] Mar 22 12:07:43 localhost pppd[1866]: sent [LCP TermAck id=0xc1] Mar 22 12:07:43 localhost pppd[1866]: rcvd [LCP TermAck id=0x2] Mar 22 12:07:43 localhost pppd[1866]: Connection terminated. This has been a one-time shot, subsequent attempts to connect fail. Now, I am very certain that I have configured the guest correctly and in principle know how to connect. This closes in my opinion the SmartOS issue I had and opens another issue with my DSL provider, which I think the list cannot help with. Thanks to all for your help, cheers, -- Christopher > On Tue, 2016-03-22 at 10:30 +0100, Christopher J. Ruwe wrote: > Hi, > > then now I understand what was meant by this thread (I found it > before, > but thought it a different matter). > > From what I gather VNICs assigned to some VLAN strip VLAN tags, so > that > the guest sees only "raw" ethernet frames. > > So then I have two options (correct?): > > 1) tag net1 on the guest with VLAN 10 via vmadm-json and work with > net1 > inside the guest without thinking about VLANs and > > 2) tag the physical NIC (DSL modem is meant to be connected to > dedicated NIC and was connected to switch only as a matter to ease > debugging/tracing net traffic) with VLAN 10. > > Is there a preferred option? The wiki-article on managing NICs > explains > how, but not when / under which circumstances. > > Thanks, > -- > Christopher > > > > > > > > On Tue, 2016-03-22 at 10:07 +0100, Adam Števko wrote: > > 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 > > /s > > ort/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 <james.blachly@gmail > > > > .c > > > > om <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/[email protected]. > > > > em > > > > ail.enqueue.archive.listbox.com/msg01152.html <https://www.mail > > > > - > > > > archive.com/smartos- > > > > [email protected]/msg > > > > 01 > > > > 152.html> > > > > > > > > > > > > James > > > > > > > > > > > > > > > > > > > On Mar 21, 2016, at 7:15 PM, Dave Finster <davefinster@icloud > > > > > .c > > > > > om <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 <adam.stevko@gmail > > > > > > .c > > > > > > om <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 <cjr@cru > > > > > > > we > > > > > > > .de <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/archiv > > > e/ > > > 184463/=now> <https://www.listbox.com/member/archive/rss/184463/ > > > 27 > > > 758409-23ef20b1> | Modify <https://www.listbox.com/member/?&;> > > > Your > > > Subscription <http://www.listbox.com/> > > > > ------------------------------------------- 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
