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
-------------------------------------------
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
