23 Aug
2013
23 Aug
'13
3:05 p.m.
Hi Guys,
Sorry about the RIP routes. After some work on my router the RIP was turned
on for all interfaces.
I have now rectified this and all should have stopped.
Apologies.
Best Regards,
Hugh G7UOD
) +44 7841 749345
* g7uod(a)onlineham.net
23 Aug
23 Aug
7:41 p.m.
Why is having rip routes sent from multiple places such a BAD thing? Is it
not a GOOD thing to have a choice on multiple redundant routes from one
place on the mesh to another? Say my direct route from node A to node B
drops, but we both can connect to node C? I could route through node C but
I don't know that route is valid unless node C tells node A about
reachability of node B and node B about reachability of node A. seems
everyone in the mesh ought to be running a dynamic routing protocol thus
increasing redundancy and reliability.
AF6EP
On Fri, Aug 23, 2013 at 1:05 AM, Hugh Golding <hugh(a)teqsys.net> wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> Hi Guys,
>
>
>
> Sorry about the RIP routes. After some work on my router the RIP was turned
> on for all interfaces.
>
>
>
> I have now rectified this and all should have stopped.
>
>
>
> Apologies.
>
>
>
> Best Regards,
>
> Hugh G7UOD
>
>
> ) +44 7841 749345
>
> * g7uod(a)onlineham.net
>
>
>
>
9:56 p.m.
On Fri, Aug 23, 2013 at 05:41:32AM -0700, Eric Fort wrote:
Why is having rip routes sent from multiple places
such a BAD thing?
It's not, as long as they have the same information. We've actually
discussed having the portal send rip44 as well, since it would be working
from the same encap database as amprgw.
Is it
not a GOOD thing to have a choice on multiple redundant routes from one
place on the mesh to another?
It might be but rip44 doesn't have that capability; if you receive different
routes from different rip44 senders they'll just flap back and forth because
there can only be one route to a destination at a time.
It could be considered an error to think of the encap table entry
as a 'route'; it's really a list of endpoints, and there is only one
endpoint per subnet possible in its definition. Rip44 is simply a way of
transmitting the encap table, not setting routes to those endpoints. The
actual routing is done by the standard operation of Internet routing
protocols at the "outer" encapsulation level.
everyone in the mesh ought to be running a dynamic
routing protocol thus
increasing redundancy and reliability.
This is a good idea. I'm not up on the latest RFCs concerning routing in
tunneled (VPN, GRE, etc) networks. Do you have a recommendation?
- Brian
25 Aug
25 Aug
1:34 p.m.
On Fri, Aug 23, 2013 at 7:56 AM, Brian Kantor <Brian(a)ucsd.edu> wrote:
I'm still a bit puzzled as to why we must use our own custom RIP daemon.
Can we not send a packet down any hole with an equal cost route and expect
it to get there? I understand we are tunneling our traffic and creating
what is essentially a rather large VPN but why ought that change things.
instead it simply grows the number of individual interfaces one must deal
with. There's likely a good reason why under IOS one has a separate
interface for each IPIP tunnel directed to a different destination.
First, I'd be inclined to look at GRE or OpenVPN over IPIP for our tunnels
simply because it is more versatile in allowing protocols other than IP to
be encapsulated inside. The ability to directly tunnel protocols other
than IP between nodes could be useful at times and be more open to
experimentation. Past that, standard RIP or possibly OSPF ought to be able
to keep track of which hole (interface) to shove packets through to send
them on to their destination. the problem now is that we seem to have a
single hole that supposedly goes to many places. If a route somehow goes
bad the dynamic routing ought be able to drop that route and use another.
is this not by definition why we use dynamic over static?
In addition to this those that wish greater internet connectivity ought
establish a connection to the apropriate AS and BGP speaker that serves
their subnet.
Eric
AF6EP
(Please trim inclusions from previous messages)
_______________________________________________
On Fri, Aug 23, 2013 at 05:41:32AM -0700, Eric Fort wrote:
If we want to have dynamic routing I'm a bit puzzled why routing
anouncements are being made by NON-Routers. Unless a device is actually
making an offer to route packets sent to it destined to the subnets it's
announcing then why are we allowing it to announce those subnets? A
routing anouncement SHOULD be construed as an offer to actually route not,
"neener, neener I know routes but I don't intend to actually help you get
there!"
Why is having rip routes sent from multiple
places such a BAD thing?
It's not, as long as they have the same information. We've actually
discussed having the portal send rip44 as well, since it would be working
from the same encap database as amprgw.
Is it
not a GOOD thing to have a choice on multiple redundant routes from one
place on the mesh to another?
It might be but rip44 doesn't have that capability; if you receive
different
routes from different rip44 senders they'll just flap back and forth
because
there can only be one route to a destination at a time.
It could be considered an error to think of the encap
table entry
as a 'route'; it's really a list of endpoints, and there is only one
endpoint per subnet possible in its definition. Rip44 is simply a way of
transmitting the encap table, not setting routes to those endpoints. The
actual routing is done by the standard operation of Internet routing
protocols at the "outer" encapsulation level.
so rip44d is not really dynamic routing then but a means to automatically
distribute a legacy database?
everyone in
the mesh ought to be running a dynamic routing protocol thus
increasing redundancy and reliability.
This is a good idea. I'm not up on the latest RFCs concerning routing in
tunneled (VPN, GRE, etc) networks. Do you have a recommendation?
- Brian
4138
days inactive
4140
days old
3 comments
3 participants
participants (3)
-
Brian Kantor -
Eric Fort -
Hugh Golding