On Mon, Jul 15, 2013 at 11:21 AM, Bob Tenty bobtenty@gmail.com wrote:
The 44 addresses not in the encap.txt should be routed to ucsd and they will hopefully tunnel them to that specific gateway. There is normally a line for that in a munge script.
I'm sorry, but I don't quite understand. If a subnet is not in encap.txt, the tunnel router in UCSD will not tunnel packets to that specific gateway - it's not much different than any other gateway in that respect, it gets its encap routing table from the very same gateways database. It doesn't have any magic deeper knowledge outside encap.txt.
Maybe, if you updated your own encap routing table very rarely, you could send unknown traffic to UCSD and hope that it updates more often, but even then:
I don't see any reason to remove BGP-announced subnets from encap.txt *except* at gateways which are doing BGP themselves or are otherwise certain that they can send out unencapsulated packets with their own net-44 source addresses. Most sites, these days, won't be able to do that, and they'll need to learn the net-44 tunnel routes somehow even for the BGP announced sites.
On 13-07-15 02:54 AM, Heikki Hannikainen wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Sun, Jul 14, 2013 at 2:04 AM, Bob Tenty bobtenty@gmail.com wrote:
There are more subnets who are announcing themselfs over Internet with BGP and who are still in the encap.txt
But but... I think they absolutely must stay in encap.txt even if a BGP announcement is place!
If they're removed, most of other traditional amprnet sites, which are not announcing their own network using BGP, cannot send packets to the BGP sites due to source address filtering (spoof protection). Most gateways these days must send out all 44-to-44 traffic encapsulated because they're only allowed to transmit out packets with their gateway's public address as the source address of the outer IP packet.