Re: [zones-discuss] traceroute to a zone creates extra hops

2006-09-13 Thread David . Comay

Fernando,

 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?


I believe you're seeing a side effect of the following bug

6426172 ICMP Destination unreachable from global zone instead
non-global

This issue is being resolved and there should be a fix in an upcoming
Nevada build.

dsc
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] traceroute to a zone creates extra hops

2006-09-13 Thread Fernando Castano


David,

thanks for letting me know that this is a bug.  Please tell me, do you 
think this would actually be an extra hop that would delay the delivery 
of the package?  We are having problems with a DNS server not resolving 
names fast enough and we suspect this is the cause.


 many thanks in advance,

 fdo

[EMAIL PROTECTED] wrote On 09/13/06 12:50,:


Fernando,

 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?



I believe you're seeing a side effect of the following bug

 6426172 ICMP Destination unreachable from global zone instead
 non-global

This issue is being resolved and there should be a fix in an upcoming
Nevada build.

dsc



--
http://www.sun.com  * Fernando Castano *
Staff engineer, MDE

*Sun Microsystems, Inc.*
260 Constitution Drive
Menlo Park, CA 94025 US
Phone x88904/+1 650 786 8904
Email [EMAIL PROTECTED]

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


Re: [zones-discuss] traceroute to a zone creates extra hops

2006-09-12 Thread Carisdad

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=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL mtu 
8232 index 1

inet 127.0.0.1 netmask ff00
ce0: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 2
inet 18.1.1.1 netmask ff00 broadcast 18.1.1.255
ether 8:0:20:fc:ef:27
hme0: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 3
inet 192.29.103.42 netmask ffe0 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=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL 
mtu  8232 index 1

 inet 127.0.0.1 netmask ff00
e1000g1: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 
1500  index 2

 inet 19.1.5.2 netmask ff00 broadcast 19.1.5.255
 ether 0:3:ba:d8:ba:2f
aggr1: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500  
index 3

 inet 18.1.1.5 netmask ff00 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=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL 
mtu  8232 index 1

 inet 127.0.0.1 netmask ff00
lo0:1: flags=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL  
mtu 8232 index 1

 zone fdoclt4z1
 inet 127.0.0.1 netmask ff00
lo0:2: flags=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL  
mtu 8232 index 1

 zone fdoclt4z2
 inet 127.0.0.1 netmask ff00
lo0:3: flags=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL  
mtu 8232 index 1

 zone fdoclt4z3
 inet 127.0.0.1 netmask ff00
ce7: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 
index 6

 inet 18.1.1.104 netmask ff00 broadcast 18.1.1.255
 ether 0:3:ba:38:b8:c8
ce7:1: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500  
index 6

 zone fdoclt4z1
 inet 18.1.1.141 netmask ff00 broadcast 18.1.1.255
ce8: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 
index 3

 inet 18.1.1.142 netmask ff00 broadcast 18.1.1.255
 ether 0:3:ba:38:b8:c8
ce8:1: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500  
index 3

 zone fdoclt4z2
 inet 18.1.1.143 netmask ff00 broadcast 18.1.1.255
ce10: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500  
index 5

 inet 18.1.1.144 netmask ff00 broadcast 18.1.1.255
 ether 0:3:ba:38:b8:c8
ce10:1: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500  
index 5

 zone fdoclt4z3
 inet 18.1.1.145 netmask ff00 broadcast 18.1.1.255
___
zones-discuss mailing list
zones-discuss@opensolaris.org

___

Re: [zones-discuss] traceroute to a zone creates extra hops

2006-09-11 Thread Fernando castano


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=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL mtu  
8232 index 1

inet 127.0.0.1 netmask ff00
ce0: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 2
inet 18.1.1.1 netmask ff00 broadcast 18.1.1.255
ether 8:0:20:fc:ef:27
hme0: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500  
index 3

inet 192.29.103.42 netmask ffe0 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=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL  
mtu  8232 index 1

 inet 127.0.0.1 netmask ff00
e1000g1: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu  
1500  index 2

 inet 19.1.5.2 netmask ff00 broadcast 19.1.5.255
 ether 0:3:ba:d8:ba:2f
aggr1: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu  
1500  index 3

 inet 18.1.1.5 netmask ff00 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=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL  
mtu  8232 index 1

 inet 127.0.0.1 netmask ff00
lo0:1:  
flags=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL  mtu  
8232 index 1

 zone fdoclt4z1
 inet 127.0.0.1 netmask ff00
lo0:2:  
flags=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL  mtu  
8232 index 1

 zone fdoclt4z2
 inet 127.0.0.1 netmask ff00
lo0:3:  
flags=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL  mtu  
8232 index 1

 zone fdoclt4z3
 inet 127.0.0.1 netmask ff00
ce7: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500  
index 6

 inet 18.1.1.104 netmask ff00 broadcast 18.1.1.255
 ether 0:3:ba:38:b8:c8
ce7:1: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu  
1500  index 6

 zone fdoclt4z1
 inet 18.1.1.141 netmask ff00 broadcast 18.1.1.255
ce8: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500  
index 3

 inet 18.1.1.142 netmask ff00 broadcast 18.1.1.255
 ether 0:3:ba:38:b8:c8
ce8:1: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu  
1500  index 3

 zone fdoclt4z2
 inet 18.1.1.143 netmask ff00 broadcast 18.1.1.255
ce10: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500   
index 5

 inet 18.1.1.144 netmask ff00 broadcast 18.1.1.255
 ether 0:3:ba:38:b8:c8
ce10:1: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu  
1500  index 5

 zone fdoclt4z3
 inet 18.1.1.145 netmask ff00 broadcast 18.1.1.255
___
zones-discuss mailing list
zones-discuss@opensolaris.org