6 Aug
2015
6 Aug
'15
5:05 p.m.
But...exactly
HOW do BGPed networks forward packets to IPENCAP
gateways via AMPRGW...since they are not directly adjacent to AMPRGW
(without a IPENCAP tunnel)???
AMPRGW would have to masquerade (or encapsulate, meaning the BGPed
subnet still needs an IPENCAP tunnel) for us, right???
Any internet host
(including a non-encap host like hamwan) trying to
get to 44-net non-BGP'd hosts send their packets to UCSD where they get
routed to amprgw. Amprgw looks up the gateway for the destination host
and encapsulates the packet and forwards it to the gateway. The sending
host doesn't have to be adjacent to UCSD; the Internet backbone takes
care of the routing to UCSD.
Any encapped packet sent to amprgw from a host on a known gateway
will be de-capsulated and placed on the Internet with the source
address that of the sending host. In that sense, amprgw is masquerading
as the sending host. Reply packets come back as above.
When troubleshooting routing problems, traceroute can be a lot more
helpful than ping. Often you can see how far the packet got.
- Brian
TNX for the info.
On this purpose, I discovered that *all* the reachable hosts like as per
the following example show the same hidden path from position
1 to position 11 so it is a mystery the track/path followed.
Furthermore the 44.0.0.1 like the hamwan.org results not pingable and
then not traceable.
gus
-----------------
root@ir0rm-7:# traceroute n1uro.ampr.org
traceroute to n1uro.ampr.org (44.88.0.9), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 n1uro.ampr.org (44.88.0.9) 346.790 ms 346.975 ms 351.388 ms