You are here

adding a permanent default route

6 posts / 0 new
Last post
wb6tae
adding a permanent default route

Where would I add a default route to be configured each time the node boots?

Specifically, I am now entering the command: ip route add default via 10.224.75.89

and I would like that to be automatic.

KG6JEI
If this is for the WAN

If this is for the WAN interface just put it in the gateway field on the setup page.

If this is for the MESH you probably do not actually want to set this, if the destination doesn't have a known route the configuration is the remote node will be responding with unreachable packets.  If the remote node does known the path you run the risk of having Inefficent RF occur as it sends the packet back to you and under a couple of select conditions it could full out routing loop on you.

We make extensive use of PBR (Policy Based Routing) in the backend to route packets and maintain isolations and security.

 

K5DLQ
K5DLQ's picture
i have a raspberry Pi that is

i have a raspberry Pi that is set for DCHP from the local node, but, it doesn't get a default route.  i haven't had time to troubleshoot.  i just add the default route command as you mentioned when i reboot it.

I really should do a tcpdump and capture that traffic....

 

wb6tae
The gateway noted in the

The gateway noted in the default route is on my home lan router (a real router) and allows me to access the mesh from anywhere on my lan. Since there is already a route for 10.0.0.0/8 out the wifi interface, only non-mesh traffic actually uses the default route.  I could change the command to be more specific, like

Ip route 192.168.4.0 via 10.224.75.101 but I still have the same issue of getting it to stick between reboots.

KG6JEI
Currently10.0.0.0/8 prefers

Currently10.0.0.0/8 prefers the DTDLink interface (lower cost interface) (You actually can't connect to the WIFI interface w/o an OLSR running now as return packets go out DTDLINK because of this.. this actually somewhat unexpectedly also reduced the attack surface of a node when it got put in)

As noted we make extensive use of PBR, the normal assumptions of "its a single unified routing table" actually goes way out the window in how these units are configured, there is a different selection of routing options based on what interface the traffic came in on (or if it was generated by the hardware itself) and what features are turned on and off on a node. (Little known fact: there are up to 2^32 routing tables on a Linux system and up to 2^32 rule priorities with each priority having a number of possible rules under it) we don't normaly touch the "default" interface rules of table 254 unless it came from LAN or the mesh node itself so the normal 10.0.0.0/8 route doesn't normally trigger on most traffic.

Since this route is not out to a mesh IP and instead is to an IP that is local to the node that should that should limit the harm that can be done (no obvious lookpbacks). I would strongly suggest limiting it and not just making it a default route however, and make sure to keep MeshGW disabled on this node if you set this, beyond that i don't see anything that obviously breaks as this should be really no different than in the scenario provided than if the IP were issued off the WAN interface (routing integrity is always a concern) since table 254 was already restricted access in our PBR setup (as long as your not a MeshGW that is) that concern goes out the window since its never going out over the RF.

Setting can be made persistent following normal config 'route' settings as documented by OpenWRT for setting up network routes.

 

wb6tae
Thanks Conrad.  My clarifying

Thanks Conrad, for clarifying the default mesh route preferred the DTDlink.  I'll check the OpenWRT docs -- actually I should have just done that first, but I was being lazy ;-)

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer