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@onlineham.net
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@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@onlineham.net
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
On Fri, Aug 23, 2013 at 7:56 AM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ 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.
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!"
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.
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.
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
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
-
Brian Kantor -
Eric Fort -
Hugh Golding