Re: [44net] Updated BGP design (was 44Net Digest, Vol 3, Issue 20)

Tnx Hessu for the correction. What I meant (and what seems logical to me) whas that if you try to reach an ampr host in the mesh network (let's call a host here M) from a bgp routed subnet, than you have tis scenario: - On the router of the upstram provider there shpuld be 2 routes. One to the BGP'd subnet (let's assume it called A 44.1.1.0/24) and one to 44.0.0.0/8 which is amprgw which is the gw for any 44 traffic. - If you try a connection from A to M, packets from A will go out "in the wild" and will be routed to amprgw, encapsulated, and sent to M, like any internet to ampr access. The responses will flow back the correct route because of conntrack. - Any two bgp enabled subntes will talk to each other like any subnet ion the internet. - Outgoing connections from M will not work since amprgw does not allow outgoing connects to 44 addresses. IMHO this rule should be refined to be "drop outgoing connections to hosts present in the encap file" which will solve the problem. But that's another thing. - Now, since A is not in the encap file, I would expect any gateway to masquerade the traffic to A to its own public IP, ensuring a regular connection to it, like a connection to any internet host. The only issue in this case is that the originator will not be identified as an ampr host, so here come those direct tunnels into play, and of course, BGP can be used internally to get dynamic routing. Allthough I favor OSPF for intranet routing. Maybe now I was more explicit :-) Marius, YO2LOJ -----Original Message----- From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Heikki Hannikainen Sent: Thursday, January 30, 2014 07:47 To: AMPRNet working group Subject: Re: [44net] Updated BGP design (was 44Net Digest, Vol 3, Issue 20) Last time I checked, amprgw could not route out any unencapsulated packets that have a destination address within 44/8. These would be packets from the IPIP-connected gateways going to a BGP-only site (most IPIP sites can not send unencapsulated outgoing packets with 44/8 source addresses due to spoofing filtering at ISPs). The reason was that UCSD's internal network routes all 44/8 destined packets to amprgw, so amprgw can not send packets to 44/8 BGP sites at all. As I understand it, currently all BGP sites must have an IPIP gateway too to enable connectivity with all the rest of the non-BGP sites.