if it can be done easy, do it complicated ! No don't
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
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.
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 ;)
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.
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
From your symptoms it sounds like the interface is not getting enabled, i.e.:
- 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:
- 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:
- ifconfig nge0 plumb 192.168.186.30/24 up
or split into several commands for step-by-step troubleshooting:
- ifconfig nge0 plumb
- ifconfig nge0 192.168.186.30/24
- ifconfig nge0 up
- 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.:
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:
rn-------------------- ----- ----- ---------- ---------
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
default 192.168.186.1 UG 1 244096
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
----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
- arp -an | grep "192.168.186.1 "
e1000g0 192.168.186.1 255.255.255.255 o 00:1b:0d:4b:93:4a
- 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 ;)
No dice, unfortunately. I added 192.168.0.0 255.255.255.0 to /etc/inet/netmasks...
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
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 22.214.171.124 255.255.255.255 S 01:00:5e:00:00:02 nge0 126.96.36.199 255.255.255.255 S 01:00:5e:00:00:16
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 :)
interesting, I forgot all about a different anomaly I logged.