On Wed, 29 Jan 2014, Marius Petrescu wrote:
And if you don't want IPIP use BGP routed acces
and you will not need it
anymore. For acces to hosts outside your network, you will be routed via
amprgw, and everything will work.
Sorry, did I accidentally miss an email or two, has something changed
around amprgw that would make the above happen?
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.
Sorry for the noise if things have changed since.
But please don't try to enforce your internal
network householding on
others, since not everyone can afford a BGP subnet. In my case a BGP enabled
acces is considered of professional use and is about my monthly income,
which of course I am not able to support.
Agreeing with all the other things you wrote!
We have a BGP setup over here now, and we are locally routing the subnets
forward with either IPIP or OpenVPN (could do GRE if needed), and we could
set up an IGP on top of those just as well.
Further, if there would be a local gateway, with a subnet within
44.139/16, that has a Gateway entry in the portal, it'd automatically get
direct IPIP routing via our BGP gateway (instead of going via UCSD)
because we have the IPIP endpoint present as well (and it gets the RIP
updates).
- Hessu, OH7LZB