if it can be done easy, do it complicated ! No don't

Added by Guenther Alka almost 3 years ago

If it comes to usability, the two most worse things i had ever discovered with
OI/ SE11 is ACL settings, ACL default for SMB and manual IP settings.

Please: Redo the dialog for IP settings

It cannot be true, that it is nearly impossible for a skilled person to set manual IP on Solaris Box via Solaris UI
see http://hardforum.com/showpost.php?p=1037296396&postcount=767

Gea


Replies (7)

RE: if it can be done easy, do it complicated ! No don't - Added by cyber ninja almost 3 years ago

Hi,
What kind of zone are you using? If the IP is on a Full root or spare root zone it is easy. you use the zonecfg command.
If it is on the global zone you need to bring the ifconfig command. If your SMB/CIFS server is not in a zone I would do that right away. Zone protect your hardware and make administering your box much easier.

Make sure that the /etc/hosts file has the right IP set for your server. Also make sure your DNS/DHCP/router/server has your static IP reserved for your server.

Here is your super easy fix! (If this is a home setup) Don't change anything on your server set your home router to always give you the same address, buy reserving it. The router is also most likely your DNS server as well you will not have any issue with name resolution. Also you can add the hostname and IP to the hosts file on computers that need to talk to SMB server. In UNIX & Linux server the hosts file is located at /etc/hosts. On Windows it is at SystemRoot\System32\drivers\etc\.

I hope this helps. If you need more info let me know.

RE: if it can be done easy, do it complicated ! No don't - Added by Jim Klimov almost 3 years ago

Well, if you are okay with the classic method of setting the configuration (with hostname files), it works (after reboot also) if you disable NWAM and reenable the default method:

svcadm disable network/physical:nwam
svcadm enable network/physical:default

I don't use graphics on servers so can't comment well on the dialogs ;)

HTH,
//Jim Klimov

RE: if it can be done easy, do it complicated ! No don't - Added by Richard PALO over 2 years ago

I'm trying to get a workstation running oi_151a to move from nwam to physical:default, but it doesn't allow outgoing/incoming connections ... but it does see the address configured.

I've tried ipadm, and since that didn't work I tried to use the hostname.nic method.
the same.

What is interesting, is that the dev-zone created upon a vnic to the physical adapter
(nge0) works just fine!!!

netstat shows the localhost, the fixed address and the default routers address but
ping gives error sendto Network not reachable.
snoop sees some messages from the router but that's about all.

The recipes listed on OpenIndiana (etc) seemingly not sufficient, is there a debug checklist to get out of nwam nightmare... (I say nightmare, because once I disabled nwam and enabled physical:default, apparently it is not straight forward to go back to nwam, so the next time beadm snapshot the system !)

Illumian won't enable (or include) NWAM, will it?

Thanks in advance

RE: if it can be done easy, do it complicated ! No don't - Added by Jim Klimov over 2 years ago

From your symptoms it sounds like the interface is not getting enabled, i.e.:

  1. ifconfig -a
    lo0:4: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
    inet 127.0.0.1 netmask ff000000
    nge0: flags=1001100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index 2
    inet 192.168.186.30 netmask ffffff00 broadcast 192.168.186.255

Check that the "UP" part is there for your interface. If it is not, enable the interface by:

  1. ifconfig nge0 up

Overall, the manual method to enable the interface from scratch (i.e. when it is not yet known to the OS, for example after you've created a VNIC and did not assign an address yet) is as follows:

  1. ifconfig nge0 plumb 192.168.186.30/24 up

or split into several commands for step-by-step troubleshooting:

  1. ifconfig nge0 plumb
  2. ifconfig nge0 192.168.186.30/24
  3. ifconfig nge0 up
To add an alias interface, do:
  1. ifconfig nge0 addif 192.168.186.31/24 up

This would create nge0:1 (or whatever alias number is free) with the given address.

This is basically what the OS initscripts did for the /etc/hostname.DRV-ID files

Your other problem might be in netmasks - if your network does not adhere to standard class subnetting (i.e. you use 10.*.*.*/24) you should define it in /etc/netmasks, i.e.:

192.168.186.0 255.255.255.0
10.1.2.64 255.255.255.192

This might bite you if, say, you try to ping 10.1.2.3 from 10.4.5.6 and your nets are /24 but the OS set them up by default as /8 - your pings won't have a reason to get to the router and to the target network; instead your host would try to find the target's MAC address and send a direct ethernet frame.

Another extreme is if you've made a typo in the netmask, and your default router IP address is actually outside your "local" subnet. For the above /etc/netmasks example, a 10.1.2.1 router would be outside the 10.1.2.64/26 subnet.

Also you might want to check if your router is accessible (pingable) with your current settings - either by ping, or if ICMP is blocked - by ARP:

  1. netstat rn
    Routing Table: IPv4
    Destination Gateway Flags Ref Use Interface
    -------------------
    -------------------- ----- ----- ---------- ---------
    default 192.168.186.1 UG 1 244096
    ...
  1. ping ns -c 3 192.168.186.1
    PING 192.168.186.1 (192.168.186.1): 56 data bytes
    64 bytes from 192.168.186.1: icmp_seq=0. time=0.890 ms
    64 bytes from 192.168.186.1: icmp_seq=1. time=1.87 ms
    64 bytes from 192.168.186.1: icmp_seq=2. time=1.87 ms
    64 bytes from 192.168.186.1: icmp_seq=3. time=2.02 ms
    ^C
    ----192.168.186.1 PING Statistics---

    4 packets transmitted, 4 packets received, 0% packet loss
    round-trip (ms) min/avg/max/stddev = 0.890/1.66/2.02/0.52
  1. arp -an | grep "192.168.186.1 "
    e1000g0 192.168.186.1 255.255.255.255 o 00:1b:0d:4b:93:4a
  1. arp 192.168.186.1
    192.168.186.1 (192.168.186.1) at 0:1b:d:4b:93:4a

Either way, at least the router's MAC address should be known if your interface is up...

There mght be more weird cases, such as MTU mismatch (jumbo vs. normal frame size), wrong MACs blocked by your switch and a lot more, but since your VNIC test worked, weird cases are probably ruled out ;)

HTH,
//Jim Klimov

RE: if it can be done easy, do it complicated ! No don't - Added by Richard PALO over 2 years ago

No dice, unfortunately. I added 192.168.0.0 255.255.255.0 to /etc/inet/netmasks...

ifconfig -a

lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
    inet 127.0.0.1 netmask ff000000 
nge0: flags=1100943<UP,BROADCAST,RUNNING,PROMISC,MULTICAST,ROUTER,IPv4> mtu 1500 index 2
    inet 192.168.0.8 netmask ffffff00 broadcast 192.168.0.255
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
    inet6 ::1/128 
nge0: flags=20002100940<RUNNING,PROMISC,MULTICAST,ROUTER,IPv6> mtu 1500 index 2
    inet6 ::/0 

arp -an

Net to Media Table: IPv4
Device   IP Address               Mask      Flags      Phys Addr
------ -------------------- --------------- -------- ---------------
nge0   192.168.0.8          255.255.255.255 SPLA     00:1d:72:a7:e5:bc
nge0   192.168.0.1          255.255.255.255 U        
nge0   224.0.0.2            255.255.255.255 S        01:00:5e:00:00:02
nge0   224.0.0.22           255.255.255.255 S        01:00:5e:00:00:16

RE: if it can be done easy, do it complicated ! No don't - Added by Jim Klimov over 2 years ago

Hmm, I am running out of ideas now. Comparing flags:

MY nge0: flags=1001100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500 index 2
YOUR nge0: flags=1100943<UP,BROADCAST,RUNNING,PROMISC,MULTICAST,ROUTER,IPv4> mtu 1500 index 2

One thing that bothers me is the PROMISC flag. I don't see that on my adapter of the system in the example even if I start a sniffer (snoop). However I do see that on another system, possibly due to VNICs enabled over this link:
e1000g0: flags=1001000943<UP,BROADCAST,RUNNING,PROMISC,MULTICAST,IPv4,FIXEDMTU> metric 2 mtu 1500 index 2
        inet 192.168.186.82 netmask ffffff00 broadcast 192.168.186.255
        ether 0:14:4f:a6:e1:ac

Another finger-pointing idea I have is the long-standing disdain for (built-in) NVidia LAN adapters. I have no idea whether it still holds true, but when they appeared on motherboards back in 2003-2005 or so they were so much looked-down upon that often built-in ports were not used in favor of add-on cards. NVidia ports used to hang or not start-up with Linux servers I've managed back then. I have rarely seen "weird" behavior of nge's in Solaris though, since they are present on many of Sun's newer AMD-series servers.

Are you sure you've ruled out any problems with networking infrastructure outside this server? For example, your router might have some static ARP entries, and 192.168.0.8 might be associated with a different MAC address than your 00:1d:72:a7:e5:bc - so that router's replies are not returning to this NIC's MAC address. Or perhaps there is IP/MAC ACL filtering or static CAM tables on your L2/L3-switches? This might explain why the VNIC works but the base adapter doesn't.

Is the firewall down, so it doesn't interfere? For example:

# ipfstat -hion
empty list for ipfilter(out)
empty list for ipfilter(in)

Did you sniff anything during your experiments, i.e. does "snoop -d nge0" show any dialog, or at least monolog?

Hell, you might be better off creating a VNIC and binding your 192.168.0.8 address to it, if this method works better for your environment, and abandon direct use of "nge0". I've actually done that on one Sun Fire X2100 router (OpenSolaris SXCE b129) with mixed nge/bge interfaces, but that's more due to naming clarity with interfaces named like "vlan186" and "vlan125". Raw names like "nge0" or "bge1" are not used at all on that system, so I can certify that this approach works :)

HTH,
//Jim

RE: if it can be done easy, do it complicated ! No don't - Added by Richard PALO over 2 years ago

interesting, I forgot all about a different anomaly I logged.
https://www.illumos.org/issues/1606

(1-7/7)