17 Jun
2015
17 Jun
'15
1:42 a.m.
Can't you put that entry back if that worked Tom?
Bob VE3TOK
On 15-06-16 09:55 PM, Tom Hayward wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On Tue, Jun 16, 2015 at 4:51 PM, Steve L <kb9mwr(a)gmail.com> wrote:
I understand the problem at hand with the
fragmentation between the
BGP vs IPIP segments. Or I think I do, from my end I know hamwan is
BGP connected and have problems reaching it:
I use the AMPR RIPv2 daemon 1.11by Marius, YO2LOJ And it appears if
the 44 address you are trying to reach isn't in the RIP list, like
hamwan is, it defaults to route it to UCSD. That doesn't work for me,
as you will see below. But when I override that, and tell it to go
out eth0 like all non 44net traffic it then works.
BTW, HamWAN used to be "in
the RIP list". The entry was deleted by an
AMPR administrator because he thought it wasn't working. We were using
44.24.221.1 as the gateway address. This address was advertised via
BGP, accessible from the internet at large, and intentionally NOT
advertised via RIP so that other gateways would not try to contact it
inside an IPIP packet. This setup was spot-checked from a number of
other AMPR systems and proven to work.
The only case where it didn't work is when administrators added a
static 44/8 route to their gateway. Note that there is no 44/8 route
in the RIP/encap list.
We're at a bit of a stalemate now. We'd have to reconfigure things a
bit and utilize another IP address from our ISP to get it running on a
non-44 gateway IP. The simpler solution (and one that serves all BGP
networks) is to work towards solving the underlying BGP/IPIP
interoperability problem that started this thread.
Tom KD7LXL
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net