rib_bogus_ipv6 was removed upstream. We need to do the same thing
and ensure that our ipv6 multipath still works
Ticket: CM-8152
Reviewed by: CCR-3775
Testing: Ran all multipath tests
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This patch lets the netlink sockets work per VRF.
* The definition of "struct nlsock" is moved into zebra/rib.h.
* The previous global variables "netlink" and "netlink_cmd" now
become the members of "struct zebra_vrf", and are initialized
in zebra_vrf_alloc().
* All relative functions now work for a specific VRF, by adding
a new parameter which specifies the working VRF, except those
functions in which the VRF ID can be obtained from the interface.
* kernel_init(), interface_list() and route_read() are now also
working per VRF, and moved from main() to zebra_vrf_enable().
* A new function kernel_terminate() is added to release the
netlink sockets. It is called from zebra_vrf_disable().
* Correct VRF ID, instead of the previous VRF_DEFAULT, are now
passed to the functions of processing interfaces or route
entries.
Signed-off-by: Feng Lu <lu.feng@6wind.com>
Reviewed-by: Alain Ritoux <alain.ritoux@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
Conflicts:
lib/memtypes.c
zebra/rib.h
zebra/rt_netlink.c
Conflicts:
zebra/if_netlink.c
zebra/if_sysctl.c
zebra/kernel_null.c
zebra/rib.h
zebra/rt_netlink.c
zebra/rt_netlink.h
zebra_vrf_enable() is the callback for VRF_ENABLE_HOOK.
It presently needs do nothing.
zebra_vrf_disable() is the callback for VRF_DISABLE_HOOK.
It presently withdraws routes, shuts down interfaces, and
clears the router-id candidates in that VRF.
Signed-off-by: Feng Lu <lu.feng@6wind.com>
Reviewed-by: Alain Ritoux <alain.ritoux@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Vincent JARDIN <vincent.jardin@6wind.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Introduce new commands to configure static routes in any VRF, by
appending the old static route commands with a new parameter
"vrf N".
A new parameter "const char *vrf_id_str" is added to the functions
zebra_static_ipv4() and static_ipv6_func() to get the configured
VRF ID.
A new member "vrf_id" is added to the "struct static_ipv4" and
"struct static_ipv6", indicating which VRF this static route is
configured in.
But till now, no interface can exist in any non-default VRF. So
these static routes in non-default VRFs are kept inactive.
Signed-off-by: Feng Lu <lu.feng@6wind.com>
Reviewed-by: Alain Ritoux <alain.ritoux@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Vincent JARDIN <vincent.jardin@6wind.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Conflicts:
zebra/zebra_rib.c
zebra/zebra_vty.c
Introduce a new "struct nexthop_vrfid" to specify a nexthop together
with the VRF ID it belongs to.
Thus in route_match_interface(), we can lookup the interface from
the correct VRF.
Signed-off-by: Feng Lu <lu.feng@6wind.com>
Reviewed-by: Alain Ritoux <alain.ritoux@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Vincent JARDIN <vincent.jardin@6wind.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Conflicts:
zebra/zebra_rib.c
zebra/zebra_routemap.c
A new member "vrf_id" is added to "struct rib", reflecting the VRF
which it belongs to.
A new parameter "vrf_id" is added to the relative functions where
need, except those:
- which already have the parameter "vrf_id"; or
- which have a parameter in type of "struct rib"; or
- which have a parameter in type of "struct interface".
All incoming routes are set to default VRF.
In fact, all routes in FIB are kept in default VRF. And the logic
is not changed.
Signed-off-by: Feng Lu <lu.feng@6wind.com>
Reviewed-by: Alain Ritoux <alain.ritoux@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Vincent JARDIN <vincent.jardin@6wind.com>
[DL: conflicts fixed + compile warning fix]
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Conflicts:
zebra/connected.c
zebra/kernel_socket.c
zebra/rib.h
zebra/rt_netlink.c
zebra/zebra_rib.c
zebra/zserv.c
Conflicts:
zebra/connected.c
zebra/interface.c
zebra/kernel_socket.c
zebra/rib.h
zebra/rt_netlink.c
zebra/rtread_getmsg.c
zebra/zebra_rib.c
zebra/zebra_vty.c
zebra/zserv.c
Previously "struct vrf" is defined locally in zebra. Now it is moved
to be a lib module.
This is the first step to support multi-VRF in quagga. The
implementation is splitted into small patches for the purpose of
easy review.
* lib:
"struct vrf" with basic members is defined in vrf.c. The member
"void *info" is for user data.
Some basic functions are defined in vrf.c for adding/deleting/
looking up a VRF, scanning the VRF table and initializing the
VRF module.
The type "vrf_id_t" is defined specificly for VRF ID.
* zebra:
The previous "struct vrf" is re-defined as "struct zebra_vrf";
and previous "vrf" variables are renamed to "zvrf".
The previous "struct vrf" related functions are removed from
zbera_rib.c. New functions are defined to maintain the new
"struct zebra_vrf".
The names vrf_xxx are reserved for the functions in VRF module.
So:
- the previous vrf_table() are renamed to zebra_vrf_table();
- the previous vrf_static_table() are renamed to
zebra_vrf_static_table().
The main logic is not changed.
BTW: Add a statement to zebra_snmp.c telling that the SNMP is
running only for the MIBs in the default VRF.
Signed-off-by: Feng Lu <lu.feng@6wind.com>
Reviewed-by: Alain Ritoux <alain.ritoux@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Vincent JARDIN <vincent.jardin@6wind.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Conflicts:
lib/Makefile.am
zebra/zebra_rib.c
zebra/zebra_vty.c
Conflicts:
lib/Makefile.am
lib/memtypes.c
zebra/rib.h
zebra/zebra_rib.c
zebra/zebra_rnh.c
zebra/zebra_rnh.h
zebra/zebra_vty.c
If you enter:
ipv6 route 2002:44:44:44::44/128 swp1 4
ipv6 route 2002:44:44:44::44/128 swp1 99
You get:
host-111# show ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv6, I - IS-IS, B - BGP, A - Babel, T - Table,
> - selected route, * - FIB route
S 2002:44:44:44::44/128 [99/0] is directly connected, swp1
S>* 2002:44:44:44::44/128 [4/0] is directly connected, swp1
This problem is fixed in the ipv4 code path. Copying the same
code from the ipv4 into the ipv6 code path fixes the issue.
With the fix:
host-111(config)# ipv6 route 2002:44:44:44::44/128 swp1 4
host-111(config)# do show ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv6, I - IS-IS, B - BGP, A - Babel, T - Table,
> - selected route, * - FIB route
S>* 2002:44:44:44::44/128 [4/0] is directly connected, swp1
C * fe80::/64 is directly connected, swp1
C>* fe80::/64 is directly connected, eth0
host-111(config)# ipv6 route 2002:44:44:44::44/128 swp1 99
host-111(config)# do show ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv6, I - IS-IS, B - BGP, A - Babel, T - Table,
> - selected route, * - FIB route
S>* 2002:44:44:44::44/128 [99/0] is directly connected, swp1
C * fe80::/64 is directly connected, swp1
C>* fe80::/64 is directly connected, eth0
host-111(config)#
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The 'struct static_ipv4' and 'struct static_ipv6' structures
are essentially the same. Collapse them into one data structure
'struct static_route'.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-7420
Reviewed By: Vivek, Donald
Testing Done: UT, verification of the fix + ospf and bgp smoke
On a link delete/down event, schedule only the prefixes which have a
static RIB too.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-7309
Reviewed By: CCR-3448
Testing Done: passing route_ospf_route_thrash, the new redist test
When zebra was modified to have redistributed routes follow a replace
logic instead of the del-add, one case was missed. When a route is
replaced with a change only to the source protocol (say from static
to bgp), its possible that the new source protocol is not selected
for redistribution by a client. Since we did not delete the route
initially, if the add is not allowed for the new source protocol
for a client, we need to send a delete of that redistributed route.
This is what the patch fixes.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-6768
Reviewed By: CCR-3207
Testing Done: bgpsmoke, smoke, topo to create failure
Redistributing routes goes through a del/add cycle whenever a redistributed
is updated. This del/add cycle causes disruption by causing traffic loss
for brief/long periods of time(6-8 s in case of OSPF). The modifications in
this patch remove the del/add cycle to ensure that this disruption doesn't
happen.
Also fixed sending no forwarding address when announcing IPv4 routes with IPv6
nexthops, and sending nexthop only when there is a single path.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-6854
Reviewed By: CCR-3297
Testing Done: bgpsmoke, bgpclos to verify setting source (in 2.5-br)
Two pieces prevented the user from specifying a route-map with set src on
IPv4 routes learnt via BGP's RFC 5549 model (v4 prefix with v6 nexthop):
- There was code missing in the section specific to 5549 in setting
the src in the netlink message
- During RIB processing, route-map processing was ignored when the NH
was v6 and the route itself was v4.
As per the code, all route-map processing that uses nexthop validates the
NH type before applying the route-map and so there should be no errors
as a consequence of relaxing bullet 2 above.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket:
Reviewed By: CCR-3335
Testing Done: bgpsmoke, ENHE tests etc.
Add support for filtering routes from upper layer protocols to zebra
via route-maps for IPv6. The same functionality already existed for
IPv4.
In addition, add support for setting source of routes via IPv6 protocol
map.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
Reviewed-by: Vipin Kumar <vipin@cumulusnetworks.com>
This adds support for BGP RFC 5549 (Extended Next Hop Encoding capability)
* send and receive of the capability
* processing of IPv4->IPv6 next-hops
* for resolving these IPv6 next-hops, itsworks with the current
next-hop-tracking support
* added a new message type between BGP and Zebra for such route
install/uninstall
* zserv side of changes to process IPv4 prefix ->IPv6 next-hops
* required show command changes for IPv4 prefix having IPv6 next-hops
Few points to note about the implementation:
* It does an implicit next-hop-self when a [IPv4 prefix -> IPv6 LL next-hop]
is to be considered for advertisement to IPv4 peering (or IPv6 peering
without Extended next-hop capability negotiated)
* Currently feature is off by default, enable it by configuring
'neighbor <> capability extended-nexthop'
* Current support is for IPv4 Unicast prefixes only.
IMPORTANT NOTE:
This patch alone isn't enough to have IPv4->IPv6 routes installed into
the kernel. A separate patch is needed for that to work for the netlink
interface.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Vivek Venkatraman <vivek@cumulusnetworks.com>
Donald Sharp <sharpd@cumulusnetworks.com>
interface or nexthop status. However, this route may not be selected as
the best and may not be the prior best. The flag needs to be reset
after evaluating the route as not doing so may prevent future nexthop
validation for this route.
Zebra currently performs a delete followed by add when a route needs to be
modified. Change this to use the replace semantics of netlink so that the
operation can possibly be atomic.
Note: Only implemented for IPv4 currently.
When a path of a static route is deleted, there is no need to reschedule and
run the RIB selection again, it is sufficient to just delete this path.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Satish Ashok <sashok@cumulusnetworks.com>
Ensure that resolution of a nexthop using a default route is not done in the
nexthop validation/update code in zebra_rib.c also. This is an addition to
the zebra-nht-no-default.patch which made the checks only in the NHT code. In
the case of scenarios like interface down, this nexthop update code will kick
in first to update the route before the NHT code comes into play; without the
additional fix, this code could incorrectly resolve the nexthop over a default
route, even when disallowed by the administrator.
BGP: Fix network import check use with NHT instead of scanner
When next hop tracking was implemented and the bgp scanner was eliminated,
the "network import-check" command got broken. This patch fixes that
issue. NHT is used to not just track nexthops, but also the static routes
that are announced as part of BGP's network command. The routes are
registered only when import-check is enabled. To optimize performance,
we register static routes only when import-check is enabled.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
When NHT calls rib_process() to be invoked for a prefix, the RIB has already
been marked as having NH changes. The first call to nexthop_active_update
clears this flag and attempts to re-determine if there are any NH changes for
a prefix. However, when the NH is recurisve, this fails. Furthermore, since
NHT has already determined that this RIB has NH changes, there's no need to
ascertain that again. The original patch used static route as the proxy to
skip this call which was incorrect since rib_process can be invoked for
static routes for reasons other than NHT. So, this patch removes the check
for static route and directly checks if the NH changed flag has been set.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
The code is structured in a way that ends up invoking zebra_delete_rnh()
multiple times which can lead to crashes and asserts. This patch fixes
the issue by setting a flag when an RNH structure is being deleted and
ignores any further attempts to delete the structure.
When a route is resolved recursively, and the recursively resolved nexthop
has the onlink attribute, the route is not programmed with the nexthop with
the onlink attribute. This patch addresses that.
Zebra: Redistribute routes from non-main kernel table to main.
This can be the basis for many interesting features such as variations
of redistribute ARP, using zebra as the RIB in the presence of multiple
routing protocol stacks etc. The code only supports IPv4 for now, but
the infrastructure is in place for IPv6.
Usage:
There is a new route type introduced by this model: TABLE. Routes
imported from alternate kernel tables will have their protocol type set to
TABLE.
Routes from alternate kernel tables MUST be first imported into the main
table via "ip import-table <table id>". They can then be redistributed via
a routing protocol via the "redistribute table" command. Each imported table
can an optional administrative distance specified. In Zebra, a route with a
lower distance is chosen over routes with a higher distance. So, distance
is how the user can choose to prioritize routes from a particular table over
routes from other tables or routes learnt another way in zebra.
Route maps for imported tables are specified via "ip protocol" command in
zebra. Route maps for redistributed routes within a routing protocol are
subject to the route map options supported by the protocol. The
"match source-protocol" option in route maps can match against "table"
to filter routes learnt from alternate kernel routing tables.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
——————————————-------------
- etc/init.d/quagga is modified to support creating separate ospf daemon
process for each instance. Each individual instance is monitored by
watchquagga just like any protocol daemons.(requires initd-mi.patch).
- Vtysh is modified to able to connect to multiple daemons of the same
protocol (supported for OSPF only for now).
- ospfd is modified to remember the Instance-ID that its invoked with. For
the entire life of the process it caters to any command request that
matches that instance-ID (unless its a non instance specific command).
Routes/messages to zebra are tagged with instance-ID.
- zebra route/redistribute mechanisms are modified to work with
[protocol type + instance-id]
- bgpd now has ability to have multiple instance specific redistribution
for a protocol (OSPF only supported/tested for now).
- zlog ability to display instance-id besides the protocol/daemon name.
- Changes in other daemons are to because of the needed integration with
some of the modified APIs/routines. (Didn’t prefer replicating too many
separate instance specific APIs.)
- config/show/debug commands are modified to take instance-id argument
as appropriate.
Guidelines to start using multi-instance ospf
---------------------------------------------
The patch is backward compatible, i.e for any previous way of single ospf
deamon(router ospf <cr>) will continue to work as is, including all the
show commands etc.
To enable multiple instances, do the following:
1. service quagga stop
2. Modify /etc/quagga/daemons to add instance-ids of each desired
instance in the following format:
ospfd=“yes"
ospfd_instances="1,2,3"
assuming you want to enable 3 instances with those instance ids.
3. Create corresponding ospfd config files as ospfd-1.conf, ospfd-2.conf
and ospfd-3.conf.
4. service quagga start/restart
5. Verify that the deamons are started as expected. You should see
ospfd started with -n <instance-id> option.
ps –ef | grep quagga
With that /var/run/quagga/ should have ospfd-<instance-id>.pid and
ospfd-<instance-id>/vty to each instance.
6. vtysh to work with instances as you would with any other deamons.
7. Overall most quagga semantics are the same working with the instance
deamon, like it is for any other daemon.
NOTE:
To safeguard against errors leading to too many processes getting invoked,
a hard limit on number of instance-ids is in place, currently its 5.
Allowed instance-id range is <1-65535>
Once daemons are up, show running from vtysh should show the instance-id
of each daemon as 'router ospf <instance-id>’ (without needing explicit
configuration)
Instance-id can not be changed via vtysh, other router ospf configuration
is allowed as before.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Honor setting source via route map and pushing that to the kernel.
With recursive routes, the ability to set the source IP address of a route
via a routemap has been broken. This patch fixes that.
To allow route map to set a source and then to unapply the route map and
have the source be taken out, I've introduced a new field in the nexthop
data structure called rmap_src. This field is zero'd before invoking the
route map apply function.
Today, no protocol daemon specifies the src in its route update to zebra.
If that happens, I didn't want to stomp on it and so have left the src
field intact instead of reusing that for the routemap to play with.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Zebra: Gather and display detailed info about clients of Zebra
The display of zebra client info is rather paltry: just the name and the FD.
For troubleshooting and general helpfulness, its useful to gather more info
about each client and display that. This patch does just that.
Zebra: Add route-map support for Next Hop Tracking
It is sometimes useful to restrict the resolution of recursive routes
to only specific via's. For example, in some configurations resolving
a route through a default route is not acceptable.
This patch adds a new route-map attach point, to zebra's next-hop-tracking
server. Whenever NHT is considering sending notification of a route
resolution, it applies a specified route-map and only if it passes, is the
NHT reachable message sent to the appropriate client protocol (BGP, OSPF etc.).
If the route-map filters the resolution, then a withdraw is sent to the
client protocol.
The route-map is sent the ip address of the route via which the resolution is
happening as well as the valid NHs associated with that route.
We also add support for matching on IP addr prefix len and source protocol
to ensure that resolution happens only via a very specific route.
Credit
------
A huge amount of credit for this patch goes to Piotr Chytla for
their 'route tags support' patch that was submitted to quagga-dev
in June 2007.
Documentation
-------------
All ipv4 and ipv6 static route commands now have a "tag" option
which allows the user to set a tag between 1 and 65535.
quagga(config)# ip route 1.1.1.1/32 10.1.1.1 tag ?
<1-65535> Tag value
quagga(config)# ip route 1.1.1.1/32 10.1.1.1 tag 40
quagga(config)#
quagga# show ip route 1.1.1.1/32
Routing entry for 1.1.1.1/32
Known via "static", distance 1, metric 0, tag 40, best
* 10.1.1.1, via swp1
quagga#
The route-map parser supports matching on tags and setting tags
!
route-map MATCH_TAG_18 permit 10
match tag 18
!
!
route-map SET_TAG_22 permit 10
set tag 22
!
BGP and OSPF support:
- matching on tags when redistribing routes from the RIB into BGP/OSPF.
- setting tags when redistribing routes from the RIB into BGP/OSPF.
BGP also supports setting a tag via a table-map, when installing BGP
routes into the RIB.
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
BGP: Reprocess the trigger points when an attached route map changes
Currently, modifications to route maps do not affect already processed
routes; they only affect new route updates. This patch addresses this
limitation.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
quagga: nexthop-tracking.patch
Add next hop tracking support to Quagga. Complete documentation in doc/next-hop-tracking.txt.
Signed-off-by: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Signed-off-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
from the protocols have ifindices and nexthop addresses in two different
structures. This patch combines them to ensure that the correct APIs can
be called. Also, given that IPV6 Linux implementation does not support the
rta_XXX APIs for multipath, the communication with the kernel is in terms
of a single nh/ifindex pair.
Quagga sources have inherited a slew of Page Feed (^L, \xC) characters
from ancient history. Among other things, these break patchwork's
XML-RPC API because \xC is not a valid character in XML documents.
Nuke them from high orbit.
Patches can be adapted simply by:
sed -e 's%^L%%' -i filename.patch
(you can type page feeds in some environments with Ctrl-V Ctrl-L)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
strip the explicit __func__ present on all calls and make the prefix
argument a transparent union.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
