show evpn mac vni all
show evpn mac vni x
does not display local svi and anycast mac into count.
Ticket:CM-20456
Testing Done:
Before:
TOR1# show evpn mac vni 1008
Number of MACs (local and remote) known for this VNI: 4
MAC Type Intf/Remote VTEP VLAN
44:38:39:00:6b:4c local vlan1008 1008
00:02:00:00:00:04 local hostbond5 1008
00:02:00:00:00:02 local hostbond4 1008
00:00:5e:00:01:01 local vlan1008-v0 1008
00:02:00:00:00:0c remote 27.0.0.15
00:02:00:00:00:0a remote 27.0.0.15
dell-s6000-07#
After:
TOR1# show evpn mac vni 1008
Number of MACs (local and remote) known for this VNI: 6
MAC Type Intf/Remote VTEP VLAN
44:38:39:00:6b:4c local vlan1008 1008
00:02:00:00:00:04 local hostbond5 1008
00:02:00:00:00:02 local hostbond4 1008
00:00:5e:00:01:01 local vlan1008-v0 1008
00:02:00:00:00:0c remote 27.0.0.15
00:02:00:00:00:0a remote 27.0.0.15
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Avoid displaying default configured local preference as
part of bgp route's detail output.
Local preference is for iBGP learnt route's. The value could be
default (100) or configured value (via routemap or local pref config cmd).
show bgp afi safi (brief output) does not display,
if the local pref attribute is not set.
Similarly, show bgp afi safi detail route output should display
if the the attribute is set, and should not display configured value.
This way both output would be consistent.
The configured local preference can be seen via running-config.
Ticket:CM-12769
Reviewed By:
Testing Done:
eBGP output:
show bgp ipv4 45.0.3.0/24
BGP routing table entry for 45.0.3.0/24
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
MSP1(uplink-1) MSP2(uplink-2)
Local
0.0.0.0 from 0.0.0.0 (27.0.0.9)
Origin incomplete, metric 0, weight 32768, valid,sourced, bestpath-from-AS Local, best
AddPath ID: RX 0, TX 7
Last update: Thu Jul 26 02:10:02 2018
iBGP output:
show bgp ipv4 unicast 6.0.0.16/32
BGP routing table entry for 6.0.0.16/32
Paths: (1 available, best #1, table default)
Not advertised to any peer
Local
6.0.0.16 (metric 20) from tor-12(6.0.0.16) (6.0.0.16)
Origin incomplete, metric 0, localpref 100, valid, internal, bestpath-from-AS Local, best
AddPath ID: RX 0, TX 13
Last update: Thu Jul 26 05:26:18 2018
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
When I did a show ip route with `json` on a vrf when it didn't exist,
frr would output invalid json.
Signed-off-by: Nathan Van Gheem <nathan@cumulusnetworks.com>
The bi->net pointer that is being unlocked had a commit
that removed the `bi->net = NULL;` recently. This code
was preventing a use after free crash being experienced
in other code paths. While commit 37e679629f was fixing
a different code path crash.
Make the parent->net pointer aware it may be locked/freed
from multiple places and to not NULL the pointer to it
unless we have actually freed the data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Modify the unlock code for a route_node to return NULL on
pointer freed or to return the node itself again.
We'll need to go through the code and fix this pattern,
but this is a problem for another day. Get this fix in
place and we can make it a low hanging problem to fix.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The parameter was missing in that vty command. Then it is being added.
Also some documentation is refreshed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
NLMSG_NEXT decrements the buffer length (status) by
the header msg length (nlmsg_len) everytime its called.
If nlmsg_len isn't accurate and set to be larger than
what it should represent, it will cause status to
decrement passed 0. This makes NLMSG_NEXT return a
pointer that references an inaccessible address.
When that is passed to NLMSG_OK, it segfaults.
Add a check to verify that there is still something to read
before we try to.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Prefix length validation checks should be returning an error
rather than 0. Switch to that and make them error messages.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Change the fuzzing code so that it fakes data from
the listening socket rather than using its own pseudo one.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add some parameter names to functions in table.h to give a
clue as to what we expect people to pass in.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Let the compiler know that this code intentionally fell
through to the next case statement in a switch.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The va_start function cannot take a object that can be type promoted
Looks like a new warning coming in from a new compiler.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Some of the parameters for lib/srcdest.. have changed to
consts, make the test cases respect that.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Packet sending in PIM is a two step process.
1) Gather data size of next G to be packed into a packet.
2) Write data
After 1 we need to ensure that the next G to pack will actually
fit in a packet. If it does not send what we've currently written
and start a new packet to send.
Because this was a 2 step process it is important to be consistent
in what you think you have packed -vs- what you think you should.
PIM has a bug where we were considering S,G RPT Prunes for a *,G
even when the *,G was being pruned. This lead to a situation where
we were figuring a write size of more data then what we actually wrote
into a packet. This would leave a 8 byte whole of 0's in the packet
due to the way we moved pointers around.
Fix the code so that we do not attempt to consider S,G rpt prunes
for a *,G prune when figuring out how much we should write in step 1.
Ticket: CM-21644
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There is a default BGP VPN and BGP VRF instance in L3VPN configuration.
The routes are imported and exported between BGP VPN and BGP VRF.
Suppose there is one route in BGP VRF and exported to BGP VPN.
In BGP VPN there is bgp_info struct with bgp_info_extra struct has parent pointer pointing to the bgp_info of BGP VRF.
We take the lock for bgp_node and bgp_info of BGP VRF in the context of BGP VPN.
bgp_info has a back pointer to bgp_node via net.
Now when we have done "no rd vpn" in BGP VRF then in bgp_info_extra_free we have to free the parent resources.
In this context only unlocking is required. It should not set the BGP VRF (bgp_info->net) to NULL.
Signed-off-by: vishaldhingra vdhingra@vmware.com
