To debug the "inactive" routes I mentioned in my previous post I did
setup the following testbed:
+------+ 10.1.1.1 10.1.1.2 +------+
+---+ 10.1.8.1| +--------------------+ |10.1.9.1 +---+
| H +-----------+ R0 | | R1 +----------+ H |
+---+ | +--------------------+ | +---+
+------+ 10.1.2.1 10.1.2.2 +------+
R0 is running my modified MTR Quagga while R1 is running unmodified
Quagga. R0's Quagga is based off R1's version of Quagga, so my MTR
changes are the only variable here. "show ip route ospf" in both routers
gives:
R1: (correct)
O 10.1.1.0/24 [110/10] is directly connected, eth4, 00:29:50
O 10.1.2.0/24 [110/10] is directly connected, eth3, 00:29:50
O>* 10.1.8.0/24 [110/20] via 10.1.2.1, eth3, 00:29:39
* via 10.1.1.1, eth4, 00:29:39
O 10.1.9.0/24 [110/10] is directly connected, eth2, 00:29:50
R0: (incorrect)
O>* 10.1.1.0/24 [110/10] is directly connected, eth2, 00:58:49
O>* 10.1.2.0/24 [110/10] is directly connected, eth3, 00:58:49
O>* 10.1.8.0/24 [110/10] is directly connected, eth4, 00:58:49
O 10.1.9.0/24 [110/20] via 10.1.1.2, eth2 inactive, 00:30:24
via 10.1.2.2, eth3 inactive, 00:30:24
It is clear that R0 has the FIB routes (marked with *) inverted. any
idea what (flag/state/?) could cause this?
I'm investigating this but I appreciate any clue from those who are more
familiar with the code.
Thanks,
Jafar
On 3/15/2016 2:52 PM, Jafar Al-Gharaibeh wrote:
Hi,
I started with the MTR code from 2010 at
https://github.com/tomhenderson/quagga-mtr/tree/mtr (mtr branch)
which was based off Quagga 0.99.17.0 and ported it to Quagga
0.99.24.1+ as of May 2015 to the last commit before introducing the
big VRF changes. I created a github repo for this at:
https://github.com/AT-Corp/quagga-atc/tree/mtr2 (mtr2 branch). I got
it to were it builds and runs successfully but I still have one
remaining issue to fix. In my test, the router that runs my MTR
enabled Quagga shows all routes learned from OSPF marked as inactive
which seems to point at a nexthop issue. Zebra doesn't push these
routes to the kernel. I will continue debugging this, but if anyone
knows a trick here I'd appreciate it.
My next step after fixing the issue above is to port the code again
post VRF and eventually to master-HEAD. I'm sticking to incremental
approach to avoid major code changes and functional surprises at the
end. The reason why I choose VRF commits as a major step in merging is
that the MTR implementation misuse some "ancient" and primitive VRF
code that existed in Quagga for a long time. MTR maps (1-1) topologies
to RIBs which are mapped (1-1) to VRFs. I view MTR as being mainly a
route optimization/selection mechanism where there could be multiple
routes to the same distention based o the class of the traffic.
Whereas VRFs provide isolation or virtualization at the router level.
This is how the recent VRF in Quagga work. That means that MTR exists
within a realm of one VRF, where one VRF could have many RIB's and
each one could be mapped to a topology. So I need to untangle MTR from
VRFs and create multiple RIB's withing a VRF to be used for different
topologies. This takes us back to an old command in Quagga "table"
that I have never seen it actually working properly that is supposed
to manage different RIB's. A recent patch shared here on the list
titled "perfect cmd table" seems to try and do just that. is there a
reason why I shouldn't use that to manage the different tables?
Thanks,
Jafar
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
