Mailing List Archive: Static route with next hop works when configured in kernel but not when configured via quagga(?)

Static route with next hop works when configured in kernel but not when configured via quagga(?)

Oct 4, 2017, 8:23 PM

Post #1 of 3 (643 views)

Hello all, My appologies for my lack of experience with the edgerouter
brand. I may confuse the names of the software packages being used by the
edgerouter for it's routing functionality. I believe that quagga is the
software router that the edgrouter pro series uses at least. If not then my
apologies for posting to the wrong list.

First my hardware setup.

I have an edge pro (unning v1.9.7+hotfix.3) connected to a meraki mx84
using an sfp cable from port #7 on the edgrouter to port #12 on the meraki.

I have the meraki configured to use ip 10.192.192.193 on port #12 and the
edgerouter configured to use 10.192.192.194 on port # 7. Both are static
ips.

I have a static route on the meraki that points 192.168.2.1 at
10.192.192.194 as the next hop.

On the edge router I have configured the web interface to point 10.64.0.0/16
to next hop via 10.192.192.193.

However I cannot ping a known host even with no firewalling between the two
networks.

I have reduced my issue down to the following:

When I configure the routes via the web interface or using the quagga
command line tools the routes are defined in the kernel as such:

ubnt@ubnt# configure
set protocols static route 10.64.0.0/16 next-hop 10.192.192.193
commit
save
exit

ubnt@ubnt# ip route show table main
default via 172.254.13.105 dev eth0 proto zebra
10.64.0.0/16 dev eth7 proto zebra
10.192.192.192/28 dev eth7 proto zebra
10.192.192.194 dev eth7 proto kernel scope link
172.254.13.104/29 dev eth0 proto kernel scope link
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1
192.168.2.0/24 dev eth2 proto kernel scope link src 192.168.2.1

However when I use the command: "ip route add" the route table looks like:

ubnt@ubnt# ip route add 10.192.192.192/28 dev eth7
ubnt@ubnt# ip route add 10.64.0.0/16 via 10.192.192.193 dev eth7

ubnt@ubnt# ip route show table main
default via 172.254.13.105 dev eth0 proto zebra
10.64.0.0/16 via 10.192.192.193 dev eth7
10.192.192.192/28 dev eth7 scope link
10.192.192.194 dev eth7 proto kernel scope link
172.254.13.104/29 dev eth0 proto kernel scope link
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1
192.168.2.0/24 dev eth2 proto kernel scope link src 192.168.2.1

When the 10.64.0.0/16 route is configured in the kernel and not via quagga
I am able to ping a host on the 10.64.0.0/16 network from the 192.168.2.0/24
network.

If I use the route created by quagga you can see that the kernel does not
know about the next hop gateway and the ping does not work. The packets
incorrectly seem to be routed to the default gateway.

Why doesn't quagga correctly add the next hop gateway to the route in the
edgerouter kernel route table?

Here you can see I have left the static route in the kernel for 10.64.0.0/16
and created a new route for 10.128.0.0/16 using quagga configure command. I
can ping addresses in the 10.64.0.0/16 range from 192.168.2.0/24 but I
cannot ping addresses in the 10.128.0.0/16 range.

ubnt@ubnt:~$ ip route show
default via 172.254.13.105 dev eth0 proto zebra
10.64.0.0/16 via 10.192.192.193 dev eth7
10.128.0.0/16 dev eth7 proto zebra
10.192.192.192/28 dev eth7 scope link
10.192.192.194 dev eth7 proto kernel scope link
172.254.13.104/29 dev eth0 proto kernel scope link
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1

ubnt@ubnt:~$ show ip route
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
> - selected route, * - FIB route, p - stale info
IP Route Table for VRF "default"
S *> 0.0.0.0/0 [1/0] via 172.254.13.105, eth0
K * 10.64.0.0/16 [0/0] via 10.192.192.193 inactive
S *> 10.128.0.0/16 [1/0] via 10.192.192.193 (recursive is directly
connected, eth7) )
K *> 10.192.192.192/28 [0/0] is directly connected, eth7
C *> 10.192.192.194/32 is directly connected, eth7
C *> 127.0.0.0/8 is directly connected, lo
C *> 172.254.13.104/29 is directly connected, eth0

Any ideas would be helpful. Thank you!

Re: Static route with next hop works when configured in kernel but not when configured via quagga(?) [ In reply to ]

quagga-users at alexis

Oct 5, 2017, 12:14 PM

Post #2 of 3 (641 views)

Permalink

On Oct 4, 2017, at 11:23 PM, Jesse Sanford <jesse@jessesanford.com> wrote:
> Hello all, My appologies for my lack of experience with the edgerouter brand. I may confuse the names of the software packages being used by the edgerouter for it's routing functionality. I believe that quagga is the software router that the edgrouter pro series uses at least. If not then my apologies for posting to the wrong list.

Edgerouter software was forked from Vyatta, part of which was forked from Quagga a long time ago. They are quite different now - the configuration CLI is entirely different. You should post this in the Ubiquiti fora unless you think there's something pertaining to the underlying routing code that is common between Ubiquiti Quagga.

/a
_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users

Re: Static route with next hop works when configured in kernel but not when configured via quagga(?) [ In reply to ]

jandrewartha at ccgs

Oct 5, 2017, 6:52 PM

Post #3 of 3 (641 views)

Permalink

On 06/10/17 03:14, Alexis Rosen wrote:
> On Oct 4, 2017, at 11:23 PM, Jesse Sanford <jesse@jessesanford.com> wrote:
>> Hello all, My appologies for my lack of experience with the edgerouter brand. I may confuse the names of the software packages being used by the edgerouter for it's routing functionality. I believe that quagga is the software router that the edgrouter pro series uses at least. If not then my apologies for posting to the wrong list.
>
> Edgerouter software was forked from Vyatta, part of which was forked from Quagga a long time ago. They are quite different now - the configuration CLI is entirely different. You should post this in the Ubiquiti fora unless you think there's something pertaining to the underlying routing code that is common between Ubiquiti Quagga.

EdgeMAX switched to using ZebOS in 1.8 as well, which is the commercial
version of the old open source Zebra, that Quagga forked from. So it's
definitely nothing to with Quagga now. http://community.ubnt.com/ is the
Ubiquiti forum btw.

--
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877
_______________________________________________
Quagga-users mailing list
Quagga-users@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-users