Fernando castano wrote:


Steffen,

 thanks for answering.  Some comments inserted.

 fdo

On Sep 7, 2006, at 9:58 AM, Steffen Weiberle wrote:

Hi Fernando,

Not sure what the problem is. You will get one line in your output if you are on the same subnet. I just tried this to an IP address on the same system and one on another system on the same network.

here is the same test, with 2 systems on the same subnet (no zones involved here). As you see, the first line in traceroute resolved to the IP I am requesting, because both are in the same subnet (so no route should be needed).

# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
        inet 18.1.1.1 netmask ffffff00 broadcast 18.1.1.255
        ether 8:0:20:fc:ef:27
hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
        inet 192.29.103.42 netmask ffffffe0 broadcast 192.29.103.63
        ether 8:0:20:fc:ef:27
# traceroute 18.1.1.31
traceroute: Warning: Multiple interfaces found; using 18.1.1.1 @ ce0
traceroute to 18.1.1.31 (18.1.1.31), 30 hops max, 40 byte packets
1  rumble2 (18.1.1.31)  0.630 ms  0.362 ms  0.354 ms

In the example I sent in the original email (involving zones), even though all systems are in the same subnet, the IP returned in the first line form traceroute is not the one I am requesting. I think that this is an extra hope that will include delay in my network communications. Isn't that true?


However, that the address responding is not the address you sent it to may be what is confusing. I'd explain this with IP using the first outbound IP address it finds, not the one the request was destined to.

the system where I issue the traceroute only has one NIC on the 181.1.0 subnet, so there is only one choice and the first IP reported by traceroute is not assigned or accessible by the zone. Why is this IP (18.1.1.142) reported by traceroute?


Steffen

Fernando castano wrote On 09/07/06 02:47,:
HI all,
I have two systems named fdo5 and fdoclt4. All the NICs in both systems are connected to the same switch. fdoclt4 has 3 zones in it. When I traceroute from fdo5 to any of the zones, the route has an extra hop (always 18.1.1.142). shouldn't this example resolve to 18.1.1.145 itself? Is there any way to correct problem?
   thanks in advance for any help,
    Fernando
------------- data -----------
hostname
fdo5
ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
         inet 127.0.0.1 netmask ff000000
e1000g1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
         inet 19.1.5.2 netmask ffffff00 broadcast 19.1.5.255
         ether 0:3:ba:d8:ba:2f
aggr1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
         inet 18.1.1.5 netmask ffffff00 broadcast 18.1.1.255
         ether 0:3:ba:d8:ba:2e
traceroute 18.1.1.145
aggr1
traceroute to 18.1.1.145 (18.1.1.145), 30 hops max, 40 byte packets
1  18.1.1.142 (18.1.1.142)  0.458 ms  0.204 ms  0.242 ms
-------------------------------------------------------------------
hostname
fdoclt4
ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
         inet 127.0.0.1 netmask ff000000
lo0:1: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
         zone fdoclt4z1
         inet 127.0.0.1 netmask ff000000
lo0:2: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
         zone fdoclt4z2
         inet 127.0.0.1 netmask ff000000
lo0:3: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
         zone fdoclt4z3
         inet 127.0.0.1 netmask ff000000
ce7: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6
         inet 18.1.1.104 netmask ffffff00 broadcast 18.1.1.255
         ether 0:3:ba:38:b8:c8
ce7:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6
         zone fdoclt4z1
         inet 18.1.1.141 netmask ffffff00 broadcast 18.1.1.255
ce8: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
         inet 18.1.1.142 netmask ffffff00 broadcast 18.1.1.255
         ether 0:3:ba:38:b8:c8
ce8:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
         zone fdoclt4z2
         inet 18.1.1.143 netmask ffffff00 broadcast 18.1.1.255
ce10: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 5
         inet 18.1.1.144 netmask ffffff00 broadcast 18.1.1.255
         ether 0:3:ba:38:b8:c8
ce10:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 5
         zone fdoclt4z3
         inet 18.1.1.145 netmask ffffff00 broadcast 18.1.1.255
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org


I've noticed this behavior as well, but we like it. It's one way to find which physical system a zone is running on. I doubt that there is much latency introduced.

-Andy
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to