Solved: Solaris/ifconfig: Establishing telnet sessions to virtual interfaces

Did you try using 'snoop' on that interface to see what happens? You might be able to capture some of the packets and understand what happens there.

Nukfror

A "ifconfig -a" output might be helpful here as well as you checking the following to make sure none of these are getting in your way:

- IPFilter
- Netmask
- hosts.allow/hosts.deny

predragpetrovic

Hi,

Could you check that the services are listening to that virtual ip address ? For every service please check that there is an static entry for the listening address (probability 95%). Also it is possible that you have an firewall on that workstation (probability 5%).

Is the virtual address on the same subnet ?

Tintin

On Solaris, telnet, ftp etc listen on any interface/address.

Most likely cause is either routing or firewall.

Hanno P.S.

Generally, the system makes no difference for eri0 and eri0:x

eri0 is just the first index, eri0:2 the second -- that's the only difference. Hence, all behave the same.
Therefore, the reason is not the interface itself, rather than some filtering (firewall?) or configuration of services (daemons).

marcusjones

ASKER

Hi all

Thanks for your suggestions so far

I was thinking that this was probably related to whether the services were running on these interfaces (as suggested by predragpetrovic)

Can anyone advise how/where this is configured?

I don't think this will be related to any firewall as this is a lab configuration so there would be no reason to run one (unless we were testing a firewall setup, that is). However, I have to say that I did not do the network setup on this so I can't be 100% sure...

Anyways, below is some further information from the systems that I tried this with:

1) Solaris interface configuration:

root@system>ifconfig -a
eri0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 1
inet 192.168.10.141 netmask ffffff00 broadcast 192.168.10.255
ether 0:3:ba:f0:c1:76
eri0:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 1
inet 16.1.1.2 netmask ffffff00 broadcast 16.255.255.255

2) Snoop for ftp session from windows client:

root@system>snoop port 21
Using device /dev/eri (promiscuous mode)
Client -> 16.1.1.2 FTP C port=4701
Client -> 16.1.1.2 FTP C port=4702
16.1.1.2 -> Client FTP R port=4702

3) Windows IP configuration:

Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.10.24
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.10.200

4) Ping from Windows to Sun

C:\>ping 16.1.1.2

Pinging 16.1.1.2 with 32 bytes of data:

Reply from 16.1.1.2: bytes=32 time<10ms TTL=255
Reply from 16.1.1.2: bytes=32 time<10ms TTL=255

5) FTP from Windows to virtual interface on Sun

C:\>ftp 16.1.1.2
Connected to 16.1.1.2.

Note: This all you get. It never get to a command prompt on the ftp session. And for Telnet there is no connection at all, although the snoop out is similar to that of the ftp session i.e. you can see the packets come in and out to try and setup the connection...

Thanks for your help

Marcus

Hanno P.S.

could you (just a try!) add the client IP address (Windows PC) into /etc/hosts to avoid problems with reverse name lookup?

predragpetrovic

Hi,

Could you give the following:

Windows:
ipconfig /all
route print

Solaris:
netstat -an
cat /etc/defaultrouter
route get -net 16.1.1.0
route get -net 192.168.10.200

marcusjones

ASKER

Many thanks for your suggestions so far

I already have a hosts file entry for the windows client, so this should be fine. The way I see it, all IP connectivity

has been confirmed by ping

The question now is one of TCP i.e. why is the service not functioning correctly on the virtual interface(?)

The requested information is shown below

1)

C:\>ipconfig /all

Windows 2000 IP Configuration

Host Name . . . . . . . . . . . . : acs2
Primary DNS Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : 3Com 3C920 Integrated Fast Ethernet Controller (3C905C-TX Compatible)
Physical Address. . . . . . . . . : 00-01-03-0C-68-A2
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.10.24
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.10.200
DNS Servers . . . . . . . . . . . :

2)

C:\>route print
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x1000003 ...00 01 03 0c 68 a2 ...... 3Com EtherLink PCI
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.10.200 192.168.10.24 1
1.1.1.0 255.255.255.0 192.168.10.200 192.168.10.24 1
10.160.20.0 255.255.255.0 192.168.10.50 192.168.10.24 1
16.1.1.2 255.255.255.255 192.168.10.141 192.168.10.24 1
30.1.1.11 255.255.255.255 192.168.10.141 192.168.10.24 1
100.100.100.0 255.255.255.0 192.168.10.251 192.168.10.24 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
151.0.0.0 255.255.255.0 192.168.10.251 192.168.10.24 1
192.168.10.0 255.255.255.0 192.168.10.24 192.168.10.24 1
192.168.10.24 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.10.255 255.255.255.255 192.168.10.24 192.168.10.24 1
192.168.11.0 255.255.255.0 192.168.10.200 192.168.10.24 1
192.168.14.16 255.255.255.255 192.168.10.244 192.168.10.24 1
192.168.20.0 255.255.255.0 192.168.10.200 192.168.10.24 1
192.168.25.0 255.255.255.0 192.168.10.237 192.168.10.24 1
192.168.100.100 255.255.255.255 192.168.10.237 192.168.10.24 1
224.0.0.0 224.0.0.0 192.168.10.24 192.168.10.24 1
255.255.255.255 255.255.255.255 192.168.10.24 192.168.10.24 1
Default Gateway: 192.168.10.200
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
192.168.20.0 255.255.255.0 192.168.10.200 1
192.168.25.0 255.255.255.0 192.168.10.237 1
192.168.100.100 255.255.255.255 192.168.10.237 1
1.1.1.0 255.255.255.0 192.168.10.200 1
10.160.20.0 255.255.255.0 192.168.10.50 1
192.168.11.0 255.255.255.0 192.168.10.200 1
100.100.100.0 255.255.255.0 192.168.10.251 1
151.0.0.0 255.255.255.0 192.168.10.251 1

C:\>

3)

UDP: IPv4
Local Address Remote Address State
-------------------- -------------------- -------
127.0.0.1.3853 Idle
*.111 Idle
*.* Unbound
*.32771 Idle
*.37 Idle
*.7 Idle
*.9 Idle
*.13 Idle
*.19 Idle
*.32772 Idle
*.32773 Idle
*.32774 Idle
*.512 Idle
*.517 Idle
*.32775 Idle
*.32776 Idle
*.32777 Idle
*.32778 Idle
*.42 Idle
*.* Unbound
*.32779 Idle
*.4045 Idle
*.514 Idle
*.123 Idle
192.168.10.141.123 Idle
127.0.0.1.123 Idle
*.* Unbound
*.* Unbound
*.161 Idle
*.32781 Idle
*.32782 Idle
*.32780 Idle
*.* Unbound
*.32783 Idle
*.177 Idle
*.32784 Idle
*.32785 Idle
*.32790 Idle
*.* Unbound
*.* Unbound
*.* Unbound
*.32891 Idle
*.* Unbound
*.* Unbound
*.* Unbound
*.* Unbound
*.877 Idle
*.* Unbound
*.* Unbound
*.* Unbound
*.* Unbound
*.* Unbound
*.33055 Idle
*.* Unbound
*.* Unbound

UDP: IPv6
Local Address Remote Address State If
--------------------------------- --------------------------------- ---------- -----
*.37 Idle
*.7 Idle
*.9 Idle
*.13 Idle
*.19 Idle
*.177 Idle

TCP: IPv4
Local Address Remote Address Swind Send-Q Rwind Recv-Q State
-------------------- -------------------- ----- ------ ----- ------ -------
*.* *.* 0 0 49152 0 IDLE
*.3852 *.* 0 0 49152 0 LISTEN
*.111 *.* 0 0 49152 0 LISTEN
*.* *.* 0 0 49152 0 IDLE
*.37 *.* 0 0 49152 0 LISTEN
*.7 *.* 0 0 49152 0 LISTEN
*.9 *.* 0 0 49152 0 LISTEN
*.13 *.* 0 0 49152 0 LISTEN
*.19 *.* 0 0 49152 0 LISTEN
*.32771 *.* 0 0 49152 0 LISTEN
*.32772 *.* 0 0 49152 0 LISTEN
*.7100 *.* 0 0 49152 0 LISTEN
*.6112 *.* 0 0 49152 0 LISTEN
*.32773 *.* 0 0 49152 0 LISTEN
*.32774 *.* 0 0 49152 0 LISTEN
*.32775 *.* 0 0 49152 0 LISTEN
*.32776 *.* 0 0 49152 0 LISTEN
*.515 *.* 0 0 49152 0 LISTEN
*.514 *.* 0 0 49152 0 LISTEN
*.514 *.* 0 0 49152 0 LISTEN
*.513 *.* 0 0 49152 0 LISTEN
*.512 *.* 0 0 49152 0 LISTEN
*.512 *.* 0 0 49152 0 LISTEN
*.79 *.* 0 0 49152 0 LISTEN
*.32777 *.* 0 0 49152 0 LISTEN
*.23 *.* 0 0 49152 0 LISTEN
*.21 *.* 0 0 49152 0 LISTEN
*.540 *.* 0 0 49152 0 LISTEN
*.32778 *.* 0 0 49152 0 LISTEN
*.4045 *.* 0 0 49152 0 LISTEN
*.32780 *.* 0 0 49152 0 BOUND
*.3853 *.* 0 0 49152 0 LISTEN
*.5987 *.* 0 0 49152 0 LISTEN
*.898 *.* 0 0 49152 0 LISTEN
*.32781 *.* 0 0 49152 0 LISTEN
*.5988 *.* 0 0 49152 0 LISTEN
*.32782 *.* 0 0 49152 0 LISTEN
*.25 *.* 0 0 49152 0 LISTEN
*.25 *.* 0 0 49152 0 LISTEN
*.587 *.* 0 0 49152 0 LISTEN
*.* *.* 0 0 49152 0 IDLE
*.32783 *.* 0 0 49152 0 LISTEN
*.32784 *.* 0 0 49152 0 LISTEN
*.32785 *.* 0 0 49152 0 LISTEN
*.22 *.* 0 0 49152 0 LISTEN
*.* *.* 0 0 49152 0 IDLE
*.27000 *.* 0 0 49152 0 LISTEN
*.33153 *.* 0 0 49152 0 LISTEN
*.* *.* 0 0 49152 0 IDLE
*.6000 *.* 0 0 49152 0 LISTEN
*.33233 *.* 0 0 49152 0 LISTEN
192.168.10.141.33235 192.168.10.141.32771 49152 0 49152 0 ESTABLISHED
192.168.10.141.32771 192.168.10.141.33235 49152 0 49152 0 ESTABLISHED
127.0.0.1.33238 127.0.0.1.33233 49152 0 49152 0 ESTABLISHED
127.0.0.1.33233 127.0.0.1.33238 49152 0 49152 0 ESTABLISHED
127.0.0.1.33241 127.0.0.1.33240 49152 0 49152 0 ESTABLISHED
127.0.0.1.33240 127.0.0.1.33241 49152 0 49152 0 ESTABLISHED
127.0.0.1.33244 127.0.0.1.33233 49152 0 49152 0 ESTABLISHED
127.0.0.1.33233 127.0.0.1.33244 49152 0 49152 0 ESTABLISHED
127.0.0.1.33247 127.0.0.1.33246 49152 0 49152 0 ESTABLISHED
127.0.0.1.33246 127.0.0.1.33247 49152 0 49152 0 ESTABLISHED
*.33349 *.* 0 0 49152 0 BOUND
192.168.10.141.33351 192.168.10.141.33153 49152 0 49152 0 ESTABLISHED
192.168.10.141.33153 192.168.10.141.33351 49152 0 49152 0 ESTABLISHED
*.33352 *.* 0 0 49152 0 LISTEN
192.168.10.141.33354 192.168.10.141.33153 49152 0 49152 0 ESTABLISHED
192.168.10.141.33153 192.168.10.141.33354 49152 0 49152 0 ESTABLISHED
*.* *.* 0 0 49152 0 IDLE
192.168.10.141.4200 *.* 0 0 49152 0 LISTEN
192.168.10.141.4100 *.* 0 0 49152 0 LISTEN
192.168.10.141.33490 192.168.10.141.33153 49152 0 49152 0 ESTABLISHED
192.168.10.141.33153 192.168.10.141.33490 49152 0 49152 0 ESTABLISHED
*.33493 *.* 0 0 49152 0 LISTEN
*.33503 *.* 0 0 49152 0 BOUND
*.9500 *.* 0 0 43952 0 LISTEN
*.9501 *.* 0 0 49152 0 LISTEN
192.168.10.141.33854 192.168.10.141.33153 49152 0 49152 0 ESTABLISHED
192.168.10.141.33153 192.168.10.141.33854 49152 0 49152 0 ESTABLISHED
192.168.10.141.33855 192.168.10.141.4100 49152 0 49152 0 ESTABLISHED
192.168.10.141.4100 192.168.10.141.33855 49152 0 49152 0 ESTABLISHED
192.168.10.141.33857 192.168.10.141.33153 49152 0 49152 0 ESTABLISHED
192.168.10.141.33153 192.168.10.141.33857 49152 0 49152 0 ESTABLISHED
192.168.10.141.33858 192.168.10.141.33493 49152 0 49152 0 ESTABLISHED
192.168.10.141.33859 192.168.10.141.4100 49152 0 49152 0 ESTABLISHED
192.168.10.141.4100 192.168.10.141.33859 49152 0 49152 0 ESTABLISHED
192.168.10.141.33493 192.168.10.141.33858 49152 0 49152 0 ESTABLISHED
127.0.0.1.33983 127.0.0.1.33233 49152 0 49152 0 ESTABLISHED
127.0.0.1.33233 127.0.0.1.33983 49152 0 49152 0 ESTABLISHED
127.0.0.1.33986 127.0.0.1.33985 49152 0 49152 0 ESTABLISHED
127.0.0.1.33985 127.0.0.1.33986 49152 0 49152 0 ESTABLISHED
*.50117 *.* 0 0 49152 0 BOUND
*.1275 *.* 0 0 49152 0 LISTEN
127.0.0.1.5600 *.* 0 0 49152 0 LISTEN
*.8077 *.* 0 0 49152 0 LISTEN
*.50143 *.* 0 0 49152 0 BOUND
*.8080 *.* 0 0 49152 0 LISTEN
192.168.10.141.50150 192.168.10.141.8089 49152 0 49152 0 CLOSE_WAIT
192.168.10.141.50172 192.168.10.236.32779 49640 0 49640 0 ESTABLISHED
192.168.10.141.50175 192.168.10.236.4100 49640 0 49416 0 ESTABLISHED
*.8009 *.* 0 0 49152 0 LISTEN
127.0.0.1.8085 *.* 0 0 49152 0 LISTEN
192.168.10.141.4430 *.* 0 0 49152 0 LISTEN
192.168.10.141.35883 192.168.10.141.33493 49152 0 49152 0 ESTABLISHED
192.168.10.141.35884 192.168.10.141.4100 49152 0 49152 0 ESTABLISHED
192.168.10.141.4100 192.168.10.141.35884 49152 0 49152 0 ESTABLISHED
192.168.10.141.33493 192.168.10.141.35883 49152 0 49152 0 ESTABLISHED
192.168.10.141.35886 192.168.10.141.33153 49152 0 49152 0 ESTABLISHED
192.168.10.141.33153 192.168.10.141.35886 49152 0 49152 0 ESTABLISHED
192.168.10.141.23 192.168.10.200.53249 3107 1 49640 0 ESTABLISHED
192.168.10.141.36961 192.168.10.141.33153 49152 0 49152 0 TIME_WAIT
192.168.10.141.36970 192.168.11.11.8080 49286 0 49425 0 TIME_WAIT
192.168.10.141.36974 192.168.11.11.8080 49286 0 49425 0 TIME_WAIT
16.1.1.2.36977 192.168.11.11.8080 0 0 49640 0 SYN_SENT
192.168.10.141.4501 *.* 0 0 49152 0 LISTEN
127.0.0.1.36981 127.0.0.1.27000 49152 0 49152 0 TIME_WAIT
192.168.10.141.36982 192.168.10.141.33153 49152 0 49152 0 ESTABLISHED
192.168.10.141.33153 192.168.10.141.36982 49152 0 49152 0 ESTABLISHED
192.168.10.141.36983 192.168.10.141.4100 49152 0 49152 0 TIME_WAIT
16.1.1.2.36984 192.168.11.11.4100 0 0 49640 0 SYN_SENT
192.168.10.141.36985 192.168.10.141.33493 49152 0 49152 0 TIME_WAIT
192.168.10.141.36987 192.168.11.11.8080 48570 0 49075 0 ESTABLISHED
*.* *.* 0 0 49152 0 IDLE

TCP: IPv6
Local Address Remote Address Swind Send-Q Rwind Recv-Q State If
--------------------------------- --------------------------------- ----- ------ ----- ------ ----------- -----
*.* *.* 0 0 49152 0 IDLE
*.37 *.* 0 0 49152 0 LISTEN
*.7 *.* 0 0 49152 0 LISTEN
*.9 *.* 0 0 49152 0 LISTEN
*.13 *.* 0 0 49152 0 LISTEN
*.19 *.* 0 0 49152 0 LISTEN
*.7100 *.* 0 0 49152 0 LISTEN
*.6112 *.* 0 0 49152 0 LISTEN
*.515 *.* 0 0 49152 0 LISTEN
*.514 *.* 0 0 49152 0 LISTEN
*.513 *.* 0 0 49152 0 LISTEN
*.512 *.* 0 0 49152 0 LISTEN
*.79 *.* 0 0 49152 0 LISTEN
*.23 *.* 0 0 49152 0 LISTEN
*.21 *.* 0 0 49152 0 LISTEN
*.25 *.* 0 0 49152 0 LISTEN
*.22 *.* 0 0 49152 0 LISTEN
*.* *.* 0 0 49152 0 IDLE
*.6000 *.* 0 0 49152 0 LISTEN
*.33493 *.* 0 0 49152 0 LISTEN

Active UNIX domain sockets
Address Type Vnode Conn Local Addr Remote Addr
30002b013a0 stream-ord 00000000 00000000 (socketpair)
30002b018f8 stream-ord 00000000 00000000
30002b01ac0 stream-ord 300016bf3d0 00000000 /tmp/.X11-unix/X0
30002b01c88 dgram 30000fd1828 00000000 /tmp/.skip.km.pipe

4)

192.168.10.200

5)

route to: 16.1.1.0
destination: 16.1.1.0
mask: 255.255.255.0
interface: eri0:2
flags: <UP,DONE>
recvpipe sendpipe ssthresh rtt,ms rttvar,ms hopcount mtu expire
0 0 0 0 0 0 1500 0
6)

route to: 192.168.10.200
destination: 192.168.10.0
mask: 255.255.255.0
interface: eri0
flags: <UP,DONE>
recvpipe sendpipe ssthresh rtt,ms rttvar,ms hopcount mtu expire
0 0 0 0 0 0 1500 0

predragpetrovic

Hi,

Well from this above there is nothing wrong. The services are listening to all addresses. I would try with the following.

1. Add another IP address to the Windows box. It is being done when you configure network interface, TCP/IP Settings and in the bottom you have "Advanced configuration" or something like that. Assign it a secondary IP address (16.1.1.0/24 network) and try to telnet.

Also are there any kind of firewall rules on the Solaris machine ?

ezaton

Of course it won't work.
Sorry for the delay, I have just looked into this.

Look, you have a machine with two addresses - 192.168.10.x and 16.1.1.x, for that matter.
Your windows machine resides on the 192.168.10.x. When you ping the 192.168.10.x address, this same interface will return a pong (the rebound of ping) sourced from the server's 192.168.10.x, and you get reply, and your services work, etc.
When you ping/access 16.1.1.x from your Windows machine, you access it through a router. A routed does not change the source IP (which is 192.168.10.x, for the client) and this packet arrives the Solaris 16.1.1.x interface correctly. The return path, however, is a bit different - your solaris wants to return an answer to the source of the packet - 192.168.10.x, and thus it must go out through the 192.168.10.x interface (per the built-in default routing!), so your client pings 16.1.1.x and gets the pong from 192.168.10.x, detects it as a fake, and ignores it. Quite simple.

To verify your virtual interface works, you can do one of the following:
1. Change the client's IP to 16.1.1.x and ping the 16.1.1.x address of the server. It will work.
2. Change the router to do more than just routing, but to run NAT on the 16.1.1.x interface, so that packets arriving the server's 16.1.1.x interface will have the source IP of the router on the 16.1.1.x network, and through its (the router) NAT table, it will be able to return the packets back to the real (and hidden!) source - the 192.168.10.x client.

Now, if this has no real reason, but only for some sort of a logical purpose, I suggest you specify eri0:2 IP as part of your internal subnet (in your case - the 192.168.10.x). This will work correctly.

ezaton

And a small add-on - I am surprised pings work. I would have expected them not to, but still, I stand behind my explanation above.

predragpetrovic

You are able to ping that address because that address is alive on the internet.

C:\Documents and Settings\predrag>tracert 16.1.1.2

Tracing route to 16.1.1.2 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms xxxxxxxxxx
2 <1 ms <1 ms <1 ms xxxxx
3 <1 ms <1 ms <1 ms xxxxxx
4 4 ms 15 ms 7 ms xxxxx
5 30 ms 35 ms 47 ms 195.29.249.137
6 29 ms 29 ms 23 ms mil14-hpt-3-hr.mil.seabone.net [195.22.205.25]
7 129 ms 128 ms 128 ms decix-fra1-racc2.fra.seabone.net [195.22.211.221]
8 48 ms 55 ms 48 ms dcix1nap.de.ip.att.net [80.81.192.199]
9 46 ms 48 ms 48 ms 165.87.217.145
10 51 ms 52 ms 52 ms 165.87.217.133
11 52 ms 52 ms 50 ms 165.87.207.117
12 50 ms 52 ms 53 ms 165.87.207.222
13 53 ms 51 ms 59 ms 165.87.161.77
14 51 ms 51 ms 51 ms 165.87.223.202

marcusjones

ASKER

Thanks for your responses guys!

I'm not sure I follow the routing arguments though...

This is a lab configuration on a stricly internal LAN - No access to the internet and very little routing to other networks

There is no intervening router. The Windows client and Sun Server are on the same LAN (same switch), so the only routing is done internally on the Sun server between the physical and virtual interfaces

I find the suggestion that the Windows box could be dropping packets quite interesting though. I just sniffed the interface during a failed Telnet connection attempt and I can see a couple of Telnet packets returned from the 16.1.1.2 source address - Why would the windows box drop these packets, when they are from the source address that it should expect(?). If indeed that is what is happening

Note: There is no firewall on the Windows client either - It's running a basic Windows 2000 install with none of the XP/Vista junk adding any interference (sorry, Microsoft :))

I guess the fact that telnet packets are returned from 16.1.1.2 at least confirms that the telnet daemon is listening on the virtual interface...

I still think I understand what is going on here. Any theories on this, given that I can see a couple of packets coming back in the trace?

Thanks

Marcus

ezaton

I need to understand your network topology better.
Let me describe it, and let me know if I'm right or wrong:
1. Your internal LAN address is 192.168.10.x, Subnet 255.255.255.0
2. Your router has an address 192.168.10.200.
3. You have many persistent routes for some unknown reason.
4. Your Solaris box has an IP of 192.168.10.141
5. Your Solaris box has another IP on the same interface with address 16.1.1.2
6. This is the mystery - does your router has an interface on the 16.1.1.x subnet?

MInd you that TCP/IP subnets have little to do with separated physical networks. TCP/IP allows segmenting to different logical "subnets" which has nothing to do with each other. It means that I can run two full different networks on the same physical infrastructure, and computers on these different networks won't be able to reach each other.

If your router (point #6) has no interface defined for 16.1.1.x subnet, then it is no wonder that the Solaris box doesn't get any communications, except for partial packets...

The missing part is the router's configuration. It can allow us some better understanding of the problem.

marcusjones

ASKER

Just noticed a typo in my last post - I meant to say that I still 'don't' understand what is going on, not that I 'do' understand what is going. That would be even more confusing ;)

So, to clarify a little about the network topology - running through each of the points in ezaton's post:

1 - Correct
2 - Correct, but the router is not involved in this issue because none of the packets are sent through it. The route to 16.1.1.2 runs through the interface on the sun box i.e. 192.168.10.141
3 - Persistent routes are there for historical reasons. To be honest I can probably remove some of them... Again, they are not relevant to this issue
4 - Correct
5 - Correct
6 - The router has no connection or route to the 16.1.1.0 subnet

So routers and firewalls have no part to play in this setup

I work in a network development lab so this is the reason for this rather simplistic setup - As far as testing is concerned, we only run what is needed to prove each concept. This is also the reason that none of these networks have any routes to the outside world!

Again, routing was proven from the outset using ping. I don't believe this was ever a question of 'routing'. Layer 3 is proven. Layer 4 upwards, I'm less sure about...

Thanks

Marcus

Hanno P.S.

Could you provide the output of
netstat -rn
on your Solaris server (equivalenz to Windows' "route print")?

marcusjones

ASKER

Thanks for your response - You're still talking routing though...

I don't follow the line of thinking but here is the output:

#netstat -rn

Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
25.1.1.11 30.1.1.1 UGH 1 1
192.168.10.0 192.168.10.141 U 1 21363 eri0
13.1.8.0 17.1.8.1 UG 1 0
12.1.8.0 16.1.8.1 UG 1 0
12.1.5.0 16.1.5.1 UG 1 0
13.1.4.0 17.1.4.1 UG 1 0
12.1.4.0 16.1.4.1 UG 1 0
13.1.5.0 17.1.5.1 UG 1 0
12.1.7.0 16.1.7.1 UG 1 0
13.1.6.0 17.1.6.1 UG 1 0
12.1.6.0 16.1.6.1 UG 1 0
13.1.7.0 17.1.7.1 UG 1 0
12.1.1.0 16.1.1.1 UG 1 8
13.1.1.0 17.1.1.1 UG 1 0
12.1.3.0 16.1.3.1 UG 1 0
14.1.1.0 17.1.2.1 UG 1 0
13.1.2.0 17.1.2.1 UG 1 0
12.1.2.0 16.1.2.0 UG 1 0
13.1.3.0 17.1.3.1 UG 1 0
16.1.1.0 16.1.1.2 U 1 37938 eri0:2
17.1.1.0 17.1.1.2 U 1 0 eri0:12
16.1.3.0 16.1.3.2 U 1 0 eri0:5
17.1.2.0 17.1.2.2 U 1 0 eri0:13
16.1.2.0 16.1.2.2 U 1 0 eri0:4
17.1.3.0 17.1.3.2 U 1 0 eri0:14
16.1.5.0 16.1.5.2 U 1 0 eri0:7
17.1.4.0 17.1.4.2 U 1 0 eri0:15
16.1.4.0 16.1.4.2 U 1 0 eri0:6
17.1.5.0 17.1.5.2 U 1 0 eri0:19
16.1.7.0 16.1.7.2 U 1 0 eri0:9
17.1.6.0 17.1.6.2 U 1 0 eri0:16
16.1.6.0 16.1.6.2 U 1 0 eri0:8
17.1.7.0 17.1.7.2 U 1 1 eri0:17
17.1.8.0 17.1.8.2 U 1 0 eri0:18
25.1.1.0 30.1.1.1 UG 1 37
16.1.8.0 16.1.8.2 U 1 0 eri0:10
30.1.1.0 30.1.1.11 U 1 42 eri0:21
224.0.0.0 192.168.10.141 U 1 0 eri0
224.0.0.0 192.168.10.141 U 1 0 eri0
default 192.168.10.200 UG 1 43941
127.0.0.1 127.0.0.1 UH 227257879 lo0
#

Hanno P.S.

For me, it looks like your IP packets travel from Windows PC to Solaris server OK but are being sent out on a different route -- that's why I'm trying to verify this.

marcusjones

ASKER

I get a response to my pings and I have also sniffed Telnet and FTP packets being returned from the 16.1.1.2 address

I think routing is fine - Unless, my understanding of TCP/IP is fundamentally wrong, which I wouldn't rule out ;)

The response is different for FTP and Telnet received back from 16.1.1.2 to that received back from 192.168.10.141 i.e. there are only 2 packets returned back from 16.1.1.2 then it stops. Whereas, with 192.168.10.141 there are more packets for the initial connection. And then of course, more come in if I do something. With 16.1.1.2, I only get 2 packets back and that's it...

ezaton

Do you allow forwarding of packets between interfaces on the Solaris?

Hanno P.S.

Please check your IP setting:
# ndd -get /dev/ip ip_forwarding

It should be "1". If not, please set with
# ndd -set /dev/ip ip_forwarding 1
and try again.

Also, check for existance of /etc/notrouter. This file should _not_ exist.

marcusjones

ASKER

Thanks for your suggestions and apologies for the delay (I work on the customer site at the beginning of each week and have no access to email whist there...)

IP forwarding was not enabled, so I tried enabling this, but the resulting behaviour is the same

Also, there was no /etc/notrouter file

marcusjones

ASKER

Hi All

A belated update on this question (apologies for the delay, I had forgotten to post the update)

Eventually, we ran this on different hardware and experienced no problems. To the best of my knowledge the configuration was the same, so my best guess was that it was somehow related to the NIC hardware i.e. eri-type interface

There is no problem setting up this lab on hme or bge-type interfaces...

Thanks for all the suggestions that were offered for this issue

Marcus

marcusjones

ASKER

This is an old problem now, and I was able to successfully logical interfaces on another Sun system using the same method, so perhaps this issue was down to the incorrectly network configuration highlighted above

I hadn't checked that and it seems plausible enough to me

Thanks for all contributions to this post

marcusjones

ASKER

No additional comments