The beauty of being BGP'ed right on the Internet?

------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays

On Thu, May 22, 2014 at 3:01 PM, Bjorn Pehrson bpehrson@kth.se wrote:

(Please trim inclusions from previous messages) _______________________________________________ Hi Marius,

I am the country coordinator of 44.140.0.0/16, which is delegated to Sweden and has transit to the Internet via SUNET, the Swedish University network. The whole /16 is announced out of AS8973, a research network under SUNET at the Royal Institite of Technology in Stockholm, although there are gateways being established with longer prefixes at SUNET PoPs in different parts of Sweden to facilitate for as many amateurs as possible to connect locally with direct radio links.

I do not know exactly where you found the information you refer to but f you make a traceroute to 44.140.0.1 you will pass 192.16.126.10 before arriving at 192.16.126.18, which is the upstream interface of the same router that has 44.140.0.1 as one of its downstreams.

I will be happy to correct whatever is wrong if you give me a hint where.

If you are curious about what we are up to there is info a www.se,ampr.org, some of it in English.

Thanks

Bjorn

On 05/22/2014 10:26 PM, Marius Petrescu wrote:

...

(Please trim inclusions from previous messages) _______________________________________________ Just peeked in th RIP broadcasts today: 44.140.0.0/16 via 44.140.0.1 This entry is invalid, since the gateway is in its own subnet and no other entry for 44.140.0.1 exists. Please correct the entry. Marius, YO2LOJ

On Thu, May 22, 2014 at 4:06 PM, Brian Kantor Brian@ucsd.edu wrote:

Unfortunately, because of the routing issues at UCSD for tunnelled hosts, that entry won't work - it isn't reachable from a tunnel and it isn't needed outside them. We're experimenting with an alternate route but as yet there is no definite answer as to whether it works. - Brian

If we're talking about IPIP tunnel endpoints, I don't see why anything at UCSD would matter. The whole point of the tunnels is to communicate directly without going through UCSD. All that matters is that the tunnel endpoint is publicly routable, which if they're announcing via BGP is the case.

Tom KD7LXL

The problem is that the route 44.140.0.0/16 via 44.140.0.1 creates a routing loop.

The moment one sets this route ont their machine, all traffic, including the one to the gateway will be encasulated and sent via the tunnel to the gateway which is impossible...

So for such a setup to work there are 3 solutions: 1) classic: 44.140.0.0/16 via 192.16.126.18

2) 2 routes: 44.140.0.1/32 via 192.16.126.18 44.140.0.0/16 via 44.140.0.1 This will break most setups since usually there is no recursive next-hop lookup on a sinlge machine GW system. In a full routed dedicated tunnel host + router combination this would work (I can give you the details).

3) don't broadcast anything at all In this case, ham traffic is treated as any regular internet traffic and nat-ed to ones public IP on their gateway (if there is no 44/8 route via UCSD), If the client is also bgp announcet, case in which it wil work flawless. The problem is that in this case you can not diferentiate ham traffic from bgp unannounced subnets from regular internet traffic on your GW side.

Talking about other solutions, I want to analyse a little the other BGP announced setup, which is correct:

44.24.240.0/20 via 44.24.221.1 44.24.221.1 is unannounced in RIP.

In this case, on a completely correct setup (which doesn't send all unknown 44s to UCSD via tunnel) will do the following: - encap all traffic to 44.24.240.0/20 - all encaped frames will be nat-ed to the local public GW IP and sent to 44.24.221.1 Of course, 44.24.221.1 has to maintain its own encap target list to be able to send traffic back to the originator, and accept proto 4 from any public IP.

So as a conclusion: Announcing BGP enabled subnets in the encap breaks some advantages of being bgp announced. It allows internet hosts to circumvent the UCSD gateway, and allows direct access to internet hosts from 44 macines without passing UCSD while maintaining its original 44 src address. But it still needs the tunnel system to allow access from 44 hosts behind tunnels. If the subnet is unannounced, only nat-ed trafic is possible from tuneled 44 systems (since UCSD routers don't forward traffic to 44 destinations).

Marius, YO2LOJ

It is not trouble, it is just a non functional route in the broadcast which prevents connections to your subnet.

So the simplest solutions would be either to announce it via RIP as a tunnel via public IP (44.140.0.0/16 via 192.16.126.18 - in this case ampr users will retain their 44 src address ) or not announce it at all in RIP/encap (and in this case everyone will appear with their public address and some will have issues because of 44.x.x.x being usually routed to UCSD by most of the setups). It will make it work in either case. Just the current setup is nonfunctional from a router's point of view without manual tuning.