Routing to ARIN from Teleglobe (2001:5a0::/32)
nenad pudar
nenad.pudar at gmail.com
Sat Feb 10 20:23:14 CET 2007
Thanks
Very good and useful tool
nenad
On 2/10/07, nenad pudar <nenad.pudar at gmail.com> wrote:
>
>
>
> On 2/10/07, Jeroen Massar <jeroen at unfix.org> wrote:
> >
> > nenad pudar wrote:
> > [ html is useless, including javascript in an email even more... ]
> >
> > > I see people resolving similar issues here(more particularly this
> > one:
> > > reachability issues to Arin : www.arin.net <http://www.arin.net>).
> > >
> > > I think there is enough info in my e-mail regarding source
> > > ,destination,as-path ,path taken etc
> >
> > Mentioning a IPv6 /32 as a source is not useful, as that allows
> > absolutely no debugging, as one can't trace anyway
>
>
>
> 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)
>
> [..]
> > > so-4-0-0-dcr1.tsd.cw.net <http://so-4-0-0-dcr1.tsd.cw.net>
> > (2001:5000:0:20::2) 52.230 ms 59.802 ms so-3-0-0-dcr1.tsd.cw.net <http://so-3-0-0-dcr1.tsd.cw.net>
> > (2001:5000:0:8e::1) 52.367 ms
> > > 10 * * *
> >
> > Ever thought of the return path?
>
>
> What I was speaking about if not about the return path ?
>
>
>
> OCCAID can't reach Teleglobe as it isn't in their routing tables.
>
>
> 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 )
>
> Solution: let those two peer, or better: let ARIN pay (or otherwise
> > arrange) for transit.
>
>
>
>
>
> Greets,
> > Jeroen
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20070210/b7203f38/attachment.htm>
More information about the ipv6-ops
mailing list