Previously, when a shortcut entry was created, its associated route was
created on system, with no nexthop, only gre device. eg:
[..]
N>* 192.168.2.0/24 [10/0] is directly connected, gre1, 00:01:04 <--- can not be resolved
[..]
Type Prefix Via Identity
dynamic 192.168.2.0/24 10.255.255.2 <---- correct
This situation was forcing neighbor resolution on the first outgoing packet matching the route entry. for instance 192.168.2.1 could not be resolved at link layer, and was going to fail. Instead, nhrp nexthop should have been used.
This is what this commit intends to do, that is to say that when a
shortcut is installed by nhrp, the associated nexthop entry is used.
[..]
N>* 192.168.2.0/24 [10/0] via 10.255.255.2, gre1 onlink, 00:00:31
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
mallinfo() is deprecated as of glibc 2.33 and emits a warning if used.
Support mallinfo2() if available.
Signed-off-by: Quentin Young <qlyoung@qlyoung.net>
Issue: When a path in the inter area ecmp route is deleted, the route is removed
Fix: The fix is to remove the specific path from the inter area route using
ospf6_abr_old_route_remove() when abr route entry is not found.
In the function ospf6_abr_old_route_remove() the path to be removed needs
to match adv router and link state ID
Fixed memory leak in ospf6_intra_prefix_update_route_origin() caused by
route node lock not getting released.
Signed-off-by: kssoman <somanks@gmail.com>
The VRF must be marked as configured when user enters "vrf NAME" command.
Otherwise, the following problem occurs:
`ip link add red type vrf table 1`
VRF structure is allocated.
`vtysh -c "conf t" -c "vrf red"`
`lib_vrf_create` is called, and pointer to the VRF structure is stored
to the nb_config_entry.
`ip link del red`
VRF structure is freed (because it is not marked as configured), but
the pointer is still stored in the nb_config_entry.
`vtysh -c "conf t" -c "no vrf red"`
Nothing happens, because VRF structure doesn't exist. It means that
`lib_vrf_destroy` is not called, and nb_config_entry still exists in
the running config with incorrect pointer.
`ip link add red type vrf table 1`
New VRF structure is allocated.
`vtysh -c "conf t" -c "vrf red"`
`lib_vrf_create` is NOT called, because the nb_config_entry for that
VRF name still exists in the running config.
After that all NB commands for this VRF will use incorrect pointer to
the freed VRF structure.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Extend the thread_cancel_event api so that it's more complete:
look in all the lists of events, including io and timers, for
matching tasks. Add a limited version of the api that only
examines tasks in the event and ready queues.
BGP appears to require the old behavior, so change its macro
to use the more limited cancel api.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
No reason for the thread/task cancellation struct to be public:
move it out of the header file. Also add a flags field.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Modify code to add JSON format output in show command.
"show ip igmp [vrf NAME] join" and "show ip igmp vrf all join" with proper formatting
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
Modify the timers on the bgp_blackhole_community test to
be more aggressive so our test system will recover faster
when we drop packets.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
`same_attr` has been computed and `hook_call(bgp_process)` (calling
BMP module) would not change it. We could reuse the value to filter
same attribute updates, avoiding an extra comparison.
Signed-off-by: zyxwvu Shi <i@shiyc.cn>
GNU Readline 8.1 enables bracketed paste by default. This results in
newlines not ending the readline() call, which breaks the ability of
users to paste in configs to vtysh's interactive shell.
Disable bracketed paste.
Signed-off-by: Quentin Young <qlyoung@qlyoung.net>
Valgrind is still reporting:
466020-==466020== by 0x11B9F4: main (bfdd.c:403)
466020-==466020== Address 0x5a7d544 is 84 bytes inside a block of size 272 free'd
466020:==466020== at 0x48399AB: free (vg_replace_malloc.c:538)
466020-==466020== by 0x490A947: qfree (memory.c:140)
466020-==466020== by 0x48F2AE8: if_delete (if.c:322)
466020-==466020== by 0x48F250D: if_destroy_via_zapi (if.c:195)
466020-==466020== by 0x497071E: zclient_interface_delete (zclient.c:2040)
466020-==466020== by 0x49745F6: zclient_read (zclient.c:3687)
466020-==466020== by 0x4955AEC: thread_call (thread.c:1684)
466020-==466020== by 0x48FF64E: frr_run (libfrr.c:1126)
466020-==466020== by 0x11B9F4: main (bfdd.c:403)
466020-==466020== Block was alloc'd at
466020:==466020== at 0x483AB65: calloc (vg_replace_malloc.c:760)
466020-==466020== by 0x490A805: qcalloc (memory.c:115)
466020-==466020== by 0x48F23D6: if_new (if.c:160)
466020-==466020== by 0x48F257F: if_create_name (if.c:214)
466020-==466020== by 0x48F3493: if_get_by_name (if.c:558)
466020-==466020== by 0x49705F2: zclient_interface_add (zclient.c:1989)
466020-==466020== by 0x49745E0: zclient_read (zclient.c:3684)
466020-==466020== by 0x4955AEC: thread_call (thread.c:1684)
466020-==466020== by 0x48FF64E: frr_run (libfrr.c:1126)
466020-==466020== by 0x11B9F4: main (bfdd.c:403)
Apparently the bs->ifp pointer is being set even in cases when
the bs->key.ifname is not being set. So go through and just
match the interface pointer and cut-to-the-chase.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Valgrind reports:
469901-==469901==
469901-==469901== Conditional jump or move depends on uninitialised value(s)
469901:==469901== at 0x3A090D: bgp_bfd_dest_update (bgp_bfd.c:416)
469901-==469901== by 0x497469E: zclient_read (zclient.c:3701)
469901-==469901== by 0x4955AEC: thread_call (thread.c:1684)
469901-==469901== by 0x48FF64E: frr_run (libfrr.c:1126)
469901-==469901== by 0x213AB3: main (bgp_main.c:540)
469901-==469901== Uninitialised value was created by a stack allocation
469901:==469901== at 0x3A0725: bgp_bfd_dest_update (bgp_bfd.c:376)
469901-==469901==
469901-==469901== Conditional jump or move depends on uninitialised value(s)
469901:==469901== at 0x3A093C: bgp_bfd_dest_update (bgp_bfd.c:421)
469901-==469901== by 0x497469E: zclient_read (zclient.c:3701)
469901-==469901== by 0x4955AEC: thread_call (thread.c:1684)
469901-==469901== by 0x48FF64E: frr_run (libfrr.c:1126)
469901-==469901== by 0x213AB3: main (bgp_main.c:540)
469901-==469901== Uninitialised value was created by a stack allocation
469901:==469901== at 0x3A0725: bgp_bfd_dest_update (bgp_bfd.c:376)
On looking at bgp_bfd_dest_update the function call into bfd_get_peer_info
when it fails to lookup the ifindex ifp pointer just returns leaving
the dest and src prefix pointers pointing to whatever was passed in.
Let's do two things:
a) The src pointer was sometimes assumed to be passed in and sometimes not.
Forget that. Make it always be passed in
b) memset the src and dst pointers to be all zeros. Then when we look
at either of the pointers we are not making decisions based upon random
data in the pointers.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Just for more debug information regarding malformed aggregator_as.
```
bgpd[5589]: [EC 33554434] 192.168.10.25: AGGREGATOR AS number is 0 for aspath: 65030
bgpd[5589]: bgp_attr_aggregator: attributes: nexthop 192.168.10.25, origin i, path 65030
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Already not necessary, because if BGP aggregator AS attribute is with
value of 0, then the attribute is already discarded at early processing.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Avoid mangling packet size which is expected to be the same as received.
Stream pointer advancing is necessary to avoid changing the packet and
reseting BGP sessions.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Add pytest marking for ospfd. This commit also has some other test markings
because I do not want to have to go through the same test multiple times.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
