Everyone, The issue turned out to be related to my ISP.
Thanks for all the help and support. On Tue, Mar 25, 2014 at 7:38 AM, Evan Rowley <[email protected]> wrote: > Robert, > Thanks for all of your insight. I appreciate the comments about how > vnics are handled. Also it's great to know that I354 is supported now. > I have some of the basic information you asked for at the end of this > message. > > The next question I have for the SmartOS community is, can someone > please QA my snoop command? I'm not an experienced snoop user, but I > think the following commands will provide the relevant information: > > snoop -o /opt/snoops/capture1 # Let this run while I ping 8.8.8.8 and > the GZ IP from the KVM guest, then ^C to stop > snoop -i /opt/snoops/capture2 -o /opt/snoops/capture3 '!(port 22)' # > Don't inlcude SSH traffic to SmartOS GZ > snoop -i /opt/snoops/capture3 -o /opt/snoops/capture4 '!(port XXXXX)' > # Don't include VNC traffic on port XXXXX > snoop -i /opt/snoops/capture4 -o /opt/snoops/capture5 > 'XXX.XXX.137.205' # Get traffic to and from KVM Guest's IP > (XXX.XXX.137.205) > snoop -v -i /opt/snoops/capture5 | less > > If that is the correct set of commands, then the output I saw in less > showed ping traffic travelling back and forth between the > XXX.XXX.137.205 KVM Guest and the SmartOS GZ XXX.XXX.136.64. The > output also showed ping traffic travelling from KVM Guest > XXX.XXX.137.205 to Google's 8.8.8.8 and even what looked like DNS > resolution traffic going to both 8.8.8.8 and 8.8.4.4 per the vmadm > JSON settings. > > My guess here is that either SmartOS is dropping packets returning to > XXX.XXX.137.205, or my ISP is behaving unexpectedly. Is there a way to > reveal dropped packets on SmartOS? On FreeBSD and OpenBSD, 'tcpdump > pflog0' can do this. > > Here is the basic info on my SmartOS installation: > > [root@00-1f-29-61-59-34 ~]# uname -a > SmartOS version is: SunOS 00-1f-29-61-59-34 5.11 > joyent_20140307T223339Z i86pc i386 i86pc > > [root@00-1f-29-61-59-34 ~]# prtconf -d > System Configuration: Joyent i86pc > Memory size: 16374 Megabytes > System Peripherals (Software Nodes): > i86pc > ... > pci, instance #0 > ... > pci8086,1f12 (pciex8086,1f12) [Intel Corporation Atom > processor C2000 PCIe Root Port 3], instance #2 > pci103c,7044 (pciex8086,105e) [Intel Corporation 82571EB > Gigabit Ethernet Controller], instance #0 > pci103c,7044 (pciex8086,105e) [Intel Corporation 82571EB > Gigabit Ethernet Controller], instance #1 > .... > > On Mon, Mar 24, 2014 at 6:55 PM, Robert Mustacchi <[email protected]> wrote: >> Hi Evan, >> >> I have some responses inline for this and also some comments based on >> your most previous e-mail. >> >> First can you please confirm what release you're running? >> >> We should have support for the Intel I354, though it will require a more >> recent platform. Support wasn't added into illumos until the beginning >> of this month. Next, can you also please confirm what the PCI ID of your >> HP NC360T is? You should be able to get that from prtconf -d. >> >> On 3/24/14 15:22 , Evan Rowley wrote: >>> The last email I sent was somewhat auto-corrected by my Android phone. >>> I apologize to anyone who was confused by the minor typos. >>> >>> [root@00-1f-29-61-59-34 ~]# nictagadm list >>> NAME MACADDRESS LINK >>> admin 00:1f:29:61:59:34 e1000g0 >>> >>> >>> ^ This looks normal. >> >> Yes, there's nothing wrong with that. >> >>> The single KVM guest I am running now is paired (somehow? I don't know >>> the exact mechanics yet) to the net0 link. >> >> Every entry in the nics array causes the creation of a virtual nic in >> the host. The first one for a given zone is called net0, the second >> net1, etc. A vnic is created over a physical nic. The physical nic is >> then programmed to receive on that mac address. If we've exceeded the >> number of mac addresses that the device supports, then it is >> transparently put into promiscuous mode. >> >>> A couple interesting things in the output for net0: >>> >>> LINK PROPERTY PERM VALUE DEFAULT POSSIBLE >>> net0 state r- unknown up up,down >>> >>> ^ The state is currently "unknown" which the rest of the links have >>> "up". I'm not sure why that is. Is it out of the ordinary? >> >> I'll have to dig into how that's generated, but I see the same state on >> our KVM instances. >> >> In general, what I'd ask is that if you snoop packets in the global >> zone, eg. run snoop -d e1000g0, do you see traffic coming from the >> guest? Keep in mind that depending on the problems that you're seeing, >> you may need to pay attention to ARP messages. What we'd like to >> ascertain is are we seeing traffic go out over the wire and if so, are >> we seeing responses come back to it and appear in the packet capture? >> >> I hope this helps point you in the right direction, let me know if >> there's something else I can clarify or suggest with respect to debugging. >> >> Robert >> >> >> ------------------------------------------- >> smartos-discuss >> Archives: https://www.listbox.com/member/archive/184463/=now >> RSS Feed: https://www.listbox.com/member/archive/rss/184463/24484565-d47e1b4e >> Modify Your Subscription: https://www.listbox.com/member/?&; >> Powered by Listbox: http://www.listbox.com > > > > -- > - EJR -- - EJR ------------------------------------------- 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
