-
Notifications
You must be signed in to change notification settings - Fork 1
Home
Welcome to the quagga-mtr wiki!
This project was developing support for OSPFv2 Multi-Topology Routing for the quagga routing suite.
This project has been dormant for about 5 years. To my knowledge, OSPF MTR has not been incorporated into quagga as of early 2016. quagga itself has evolved quite a bit since that time, so some porting effort is likely required to use this code.
The master branch is cloned from quagga upstream (code.quagga.git/quagga.git). The MTR code is in the mtr branch. The MTR code is branched from the quagga_0_99_17_release tag changeset.
To access the MTR code, you must clone this repository, and then checkout the MTR branch, such as ` git clone [email protected]:tomhenderson/quagga-mtr.git git checkout mtr
Please mark issues in our Issues tracker on this site. There is presently no mailing list for this project, so please use quagga-dev or contact ([email protected]).
My next priority was to redo the zebra support to avoid using VRFs, but I never found the time. I do not have any immediate plans to add support for type 3/5/7 LSAs (see below scope section), so patches would be welcome there.
RFC 4915 is supported except for the following features.
-
The current patch enables operation in single-area configurations. Inter-area and external routing support is planned for April completion. The following sections of RFC contain specification of this capability and are not fully supported yet.
- Section 3.4.1. Inter-Area and External Routing
- Section 4.5 OSPF LSA Advertisement and SPF Computation for Excluded Links (elements pertaining to Type-5 and Type-7 LSAs)
- Appendix B.3. Summary-LSAs
- Appendix B.4. AS-external-LSAs
- Appendix B.5. Type-7 AS-external-LSAs
-
Demand circuit extensions (Section 5.1) are not planned since quagga ospfd does not support demand circuit.
./configure --enable-user=root --enable-group=root --enable-vtysh --with-cflags=-ggdb
make
make install
which installs the software into /usr/local/bin, /usr/local/etc, and /usr/local/sbin. Note that to specify an alternate installation directory, the --enable-prefix option can be passed to configure.
The software may be configured through the vtysh or through configuration files such as ospfd.conf or unified Quagga.conf. In an MTR-enabled network, there is a “default” topology (or topology “0”) and there are possibly other numbered topologies. IANA allocations for the MT-ID space are as follows:
Since AS-External-LSAs use the high-order bit in the MT-ID field (E-bit) for the external metric-type, only MT-IDs in the 0 to 127 range are valid. The following MT-ID values are reserved:
0 - Reserved for advertising the metric associated
with the default topology (see Section 4.2)
1 - Reserved for advertising the metric associated
with the default multicast topology
2 - Reserved for IPv4 in-band management purposes
3-31 - Reserved for assignments by IANA
32-127 - Reserved for development, experimental and
proprietary features [RFC3692]
128-255 - Invalid and SHOULD be ignored
The “default exclusion” capability is a mode of MTR operation that governs whether the default (topology 0) metric is advertised in the legacy metric field or as MT-ID 0. When default exclusion is enabled, the legacy metric is ignored and the default topology is drawn from the MT-ID 0 metrics. When default exclusion is disabled, the legacy metric will be used for the default topology, and any metrics for MT-ID 0 will be ignored in the SPF.
The setting of the default exclusion capability has area scope, and all routers in an MTR-enabled network should have the same setting. By default, this capability is disabled. To enable, add this statement to the router configuration block:
router ospf
area 0.0.0.0 mt-default-exclusion
!
or if configuring by vtysh, the commands:
area 0.0.0.0 mt-default-exclusion
no area 0.0.0.0 mt-default-exclusion
The setting of an MT-ID cost is similar to that of setting a default cost, only that the “mt-id ” specifier is placed before the cost; for example:
interface eth1
ip ospf cost 3
ip ospf mt-id 42 cost 24
...
Correct operation of the protocol can be validated by inspecting the run-time configuration and databases based on configuration options, and use of the valgrind software analysis tool.
An MTR-enabled implementation can be detected by performing a show run command at the top level vtysh prompt, which should display something like this:
node_A# show ip ospf
OSPF Routing Process, Router ID: 0.0.0.47
This implementation conforms to RFC2328
Supports RFC4915 Multi-Topology (MT) Routing
...
The Supports RFC4915 ... string should be present.
To observe what kind of routing tables are built at the OSPF layer, the “show ip ospf route” command can be invoked.
To check whether MTR-computed routes actually make it into Linux forwarding tables, the iproute2 utility can be used to display these tables. ip route show table 254 will show the main Linux routing table, and ip route show table <N> will show the table N routing table (N is an integer less than 256).
The current implementation abuses the existing (incomplete) zebra virtual routing and forwarding instances (VRF) to store multiple RIBs at the zebra level. There is no way to display a multi-topology RIB from zebra; only the base topology is shown when “show ip route” command is issued in vtysh (although “show ip ospf route” shows the multi-topology routes at the OSPFv2 level). An item for future work is to move away from implementing this as VRFs and instead add another dimension to the RIB table array; that is, for an existing AFI and SAFI, there are more than one RIB.
This API could be slightly aligned to match better with Cisco MTR API. For instance, default-exclusion is enabled as a “capability” in Cisco IOS.
Resolve policy issue on whether coding of mt-id 1 or 2 results in a hard or soft error.
Resolve policy issue on whether coding of mt-id 0 when default exclusion is disabled should result in a hard error.
In preparing the patch, we detected inconsistent use of netlink RT_TABLE_MAIN vs RT_TABLE_UNSPEC throughout the existing codebase.
quagga-0.99.17 does not produce a clean valgrind upon program termination; this patch does not introduce new issues but does not fix the underlying issues with quagga.
When default exclusion is disabled but mt-id values of 0 are present in the configuration, need to resolve whether mt-id 0 should be visible from vtysh show ip ospf route