Thanks<br><br>Very good and useful tool<br><br>nenad<br><br><div><span class="gmail_quote">On 2/10/07, <b class="gmail_sendername">nenad pudar</b> <<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
<br>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>