Date: Wed, 17 Dec 2008 11:01:55 +0530 From: "TCP IP" <tcp.ip.ip6@gmail.com> Subject: [users:01048] Re: Question about IPv6 Ready Phase 2 Interoperability To: users@tahi.org Message-Id: <ba28e1060812162131q181d9a78q37aa7402b0cac87e@mail.gmail.com> In-Reply-To: <f051005f0812161949ud67991ch5402979c92a616a6@mail.gmail.com> References: <f051005f0812161905t3371c3a5w888cc10bd85fcd9b@mail.gmail.com> <494873F0.7050408@redhat.com> <f051005f0812161949ud67991ch5402979c92a616a6@mail.gmail.com> X-Mail-Count: 01048Hello, Even when i test i got 33% of packet loss., but i think that is worng. becuse the n/w topology looks as follows. MC1 | ----------+------------+--------------------- N/W1 MTU 1500 | MC2 | ---------+----------------+-------------------- N/W2 MTU 1280 | MC3 | -----+-------------------+----------------------- N/W3 MTU 1500 | MC4 In script we ping 3 time from MC4 to MC1 as follows. Ping -c 1 -c 1452 MC1 ( 100% packet loss) Ping -c 1 -c 1452 MC1 ( 100% packet loss) Ping -c 3-c 1452 MC1 ( 33% packet loss) Yes, 1st ping will get too big messge from MC3 and MC4 will reduce its PMTU to 1280. and 2nd ping will reach MC1. The MC1 will try to reply with MTU 1500, so it also will get Too big message from MC2.( 2packet lost ) Now, MC1 and MC4 knows it PMTU, the last ping has to 0 % packet loss right? Am i missiing anything here? On 12/17/08, Rommel Laranjo <rslaranjo@gmail.com> wrote: > > Thank you so much wang_jiabo for your reply. So now I think there is > something wrong with my setup cause I experience huge percentage of packet > drop. > From my packet sniff on Network1, I've seen several ICMPv6 Echo reply but > only few were received by TAR-Router1. > > Thanks alot, > > Rommel > > > > On Wed, Dec 17, 2008 at 11:37 AM, wang_jiabo <jiabwang@redhat.com> wrote: > >> Hello, Rommel Laranjo: >> my test result for 1.6 part D: >> >> Rommel Laranjo ping6 -I eth0 -c 3 -s 1500 3ffe:501:ffff:104::1 > >> 1.6.D.RedHat.Cisco.result >> >> PING 3ffe:501:ffff:104::1(3ffe:501:ffff:104::1) from >> 3ffe:501:ffff:100:210:18ff:fe32:56e2 eth0: 1500 data bytes >> From 3ffe:501:ffff:100::1 icmp_seq=0 Packet too big: mtu=1280 >> 1508 bytes from 3ffe:501:ffff:104::1: icmp_seq=1 ttl=62 time=2.06 ms >> 1508 bytes from 3ffe:501:ffff:104::1: icmp_seq=2 ttl=62 time=2.13 ms >> >> --- 3ffe:501:ffff:104::1 ping statistics --- >> 3 packets transmitted, 2 received, +1 errors, 33% packet loss, time 2000ms >> rtt min/avg/max/mdev = 2.061/2.100/2.139/0.039 ms, pipe 2 >> >> >> [H3CMSR2020]ping ipv6 -s 1500 3ffe:501:ffff:100:210:18ff:fe32:56e2 >> PING 3ffe:501:ffff:100:210:18ff:fe32:56e2 : 1500 data bytes, press >> CTRL_C to break >> Reply from 3FFE:501:FFFF:100:210:18FF:FE32:56E2 >> bytes=1500 Sequence=1 hop limit=62 time = 2 ms >> Reply from 3FFE:501:FFFF:100:210:18FF:FE32:56E2 >> bytes=1500 Sequence=2 hop limit=62 time = 2 ms >> Reply from 3FFE:501:FFFF:100:210:18FF:FE32:56E2 >> bytes=1500 Sequence=3 hop limit=62 time = 3 ms >> Reply from 3FFE:501:FFFF:100:210:18FF:FE32:56E2 >> bytes=1500 Sequence=4 hop limit=62 time = 3 ms >> Reply from 3FFE:501:FFFF:100:210:18FF:FE32:56E2 >> bytes=1500 Sequence=5 hop limit=62 time = 3 ms >> >> --- 3ffe:501:ffff:100:210:18ff:fe32:56e2 ping statistics --- >> 5 packet(s) transmitted >> 5 packet(s) received >> 0.00% packet loss >> round-trip min/avg/max = 2/2/3 ms >> >> I hope this can help you. >> jiabo >> >> Hello to all tahi users, >>> >>> I know this post is not related to using the TAHI script because I'm >>> doing manual IPv6 Interoperability Testing. >>> But I just hope someone would be kind enough to share their expert >>> knowledge about Interoperability Testing. >>> >>> I am now performing Test IP6Interop.1.6: Path MTU Discovery and >>> Fragmentation Part D steps 23 to 27. My question is this, is it normal to >>> see packet loss about 90% or sometimes 80% when I ping from TAR-Router1 to >>> TAR-Host1 ? and from TAR-Host1 to TAR-Router1 ? >>> If there would be packet loss, how much would be the expected value? >>> I gladly appreciate your replies. >>> >>> >>> Thanks, >>> >>> Rommel >>> >>> >> >> >1048_2.html (attatchment)(tag is disabled)