Thanks Very good and useful tool nenad <div><span class="gmail_quote">On 2/10/07, <b class="gmail_sendername">nenad pudar <<a href="mailto:nenad.pudar@gmail.com">nenad.pudar@gmail.com</a>> wrote:

</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br><div><span class="q"><span class="gmail_quote">On 2/10/07, <b class="gmail_sendername">

Jeroen Massar</b> <<a href="mailto:jeroen@unfix.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">jeroen@unfix.org</a>> wrote:</span></span><span class="q"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

nenad pudar wrote:<br>[ html is useless, including javascript in an email even more... ]<br><br>> I see  people resolving similar issues here(more particularly this one:<br>> reachability issues  to Arin :<a href="http://www.arin.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

www.arin.net</a> <<a href="http://www.arin.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.arin.net</a>>).<br>><br>> I think there is enough info in my e-mail regarding source

<br>> ,destination,as-path ,path taken etc<br><br>Mentioning a IPv6 /32 as a source is not useful, as that allows

<br>absolutely no debugging, as one can't trace anyway</blockquote></span><div><br><br>This is not true (It is true in the case in which one is  complaining about the reachability issue from specific host which is not the case her ,the whole /32 network is in question ,so you van do trace for anything inside that /32)

<br></div><span class="q"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">[..]<br>> <a href="http://so-4-0-0-dcr1.tsd.cw.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

so-4-0-0-dcr1.tsd.cw.net

</a> <<a href="http://so-4-0-0-dcr1.tsd.cw.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://so-4-0-0-dcr1.tsd.cw.net</a>> (2001:5000:0:20::2)  52.230 ms  59.802 ms <a href="http://so-3-0-0-dcr1.tsd.cw.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

so-3-0-0-dcr1.tsd.cw.net</a> <<a href="http://so-3-0-0-dcr1.tsd.cw.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://so-3-0-0-dcr1.tsd.cw.net</a>> (2001:5000:0:8e::1)  52.367 ms<br>> 10  * * *<br><br>Ever thought of the return path?</blockquote></span><div><br>What I was speaking about if not about the return path ?<br><br>

 </div><span class="q">

<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">OCCAID can't reach Teleglobe as it isn't in their routing tables.</blockquote></span>

<div>

<br>Naturally I thought that may be issue ,but not necessarily at this stage of ipv6 internet .It is known that some peering sessions are configured as a transit   (full bgp v6 table exchanged as opposed to customer-routes only )

<br></div><span class="q"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Solution: let those two peer, or better: let ARIN pay (or otherwise

arrange) for transit.

</blockquote><div><br><br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Greets,<br> Jeroen<br><br><br></blockquote></span></div>

<br>

</blockquote></div><br>