Add a couple more tests to static route installation
Do some very very basic work to make sure that they are working
the way we want.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1. Added 1 test case to verify NO-ADVERTISE Community functionality
2. Enhanced bgp.py to exclude routers from verification, if doesn't have bgp config
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
1. Added 2 new test cases to bgp-basic-functionality-topo1
2. Enhanced 2 tests to run for both static routes and network advvertise command
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
1. Added 5 test cases to verify BGP AS-allow-in behavior in FRR
2. Enhanced framework to support BGP AS-allow-in config(lib/bgp.py)
3. Added API in bgp.py to verify BGP RIB table(lib/bgp.py)
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
take into account polychaeta tips ono code style.
also, take into account miscellaneous code style recommandations like
braces usage.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When the Independent Control mode is in use (the default one),
each LDP speaker allocates labels independently, which can lead to
broken LSPs when the LDP and IGP domains are not congruent.
What we were doing in this case was to drop all packets coming
through a broken LSP, which causes drastic side effects in the
network like loss of IP connectivity between routers.
We can however do a best-effort attempt to avoid packet loss by
popping the top-level label of the incoming packets and forwarding
them normally to their nexthops. This will be enough to guarantee
that labeled IP packets will reach their final destination. The
broken LSPs will still be unsuitable to tunnel labeled traffic, like
VPN packets, but in this case there's nothing we can do about it.
Cisco's IOS does something similar, called the "Untagged/No Label"
operation, which removes the entire label stack and forward the
packet unlabeled. We don't have such functionality available in the
Linux kernel, but this shouldn't make any difference for practical
purposes.
Fixes#6127.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
for some reason, when issuing a 'no metric-style' command we were
setting the metric-style to narrow, even though the default is
actually wide. Use NULL to avoid similar problems in the future.
Likewise, the 'no is-type' command was still trying to implement
the old logic of applying a different default for the first area.
In practice this had no effect because the value would now be the
same in both cases, but it's better to remove useless code anyway.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
When default route is requested from client, default
route is sent to client if present. When route gets
deleted then delete is sent to clients.
Signed-off-by: Santosh P K <sapk@vmware.com>
Use more limited matching logic so that nexthops within a
nexthop-group are unique based only on vrf, type, and gateway.
Treat configuration of a nexthop that matches an existing
nexthop as a replace operation.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
zebra should only check whether a get_chunk operation succeeded
when processing the response, rather than insde the get_chunk
call itself. Spllitting the request and response hooks was done
precisely to allow for asynchronous calls to an external label
manager; in this case, the requested chunk is not necessarily
going to be available at request time.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
Valid range for hashmasklen is 0-32 under IPv4; failure to validate this
results in a negative bitshift later
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This test creates a 5 box setup with 2 hosts, 2 PEs and a P router
it checks for
1. VNI VTEPs being communicated between zebra from PE1 to PE2
and vice versa.
2. MAC addresses from host 1 being learned by PE1 and signalled
to PE2 over BGP
Signed-off-by: Pat Ruddy <pat@voltanet.io>
Yang constraints enforced by the northbound callbacks require that
the maximum lifetime be >= than (refresh interval + 300). When we are
moving from one config to another through frr-reload.py, we issue
a number of vtysh -c commands ('no lsp-refresh-interval level-1 500',
'no max-lsp-lifetime level-1 1000'), which reset these parameters to their
default values, respectively 900 and 1200. Depending on the actual
values in the current config, the order in which these commands are sent
might be the wrong one, in that we hit an invalid intermediate state and
make vtysh (and by extension frr-reload.py) return an error.
As a workaround, let's add a one-liner command that sets all these
inter-related parameters in one go, and make isisd display them as a
single line too, so that the diff will be computed as a single command.
The old individual commands are kept to ensure backwards compatibility.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
Multiple different issues causing mostly UAFs but maybe other more
subtle things.
- Cluster lists were the only attributes whose pointers were not being
NULL'd when freed, resulting in heap UAF
- When performing an insert into the cluster hash, our temporary struct
used for hash_get() was inconsistent with our hash keying and
comparison functions. In the case of a zero length cluster list, the
->length field is 0 and the ->list field is NULL. When performing an
insert, we set the ->list field regardless of whether the length is 0.
This resulted in the two cluster lists hashing equal but not comparing
equal. Later, when removing one of them from the hash before freeing
it, because the key matched and the comparison succeeded (because it
was set to NULL *after* the search but *before* inserting into the
hash) we would sometimes release the duplicated copy of the struct,
and then free the one that remained in the hash table. Later accesses
constitute UAF. This is fixed by making sure the fields used for the
existence check match what is actually inserted into the hash when
that check fails.
This patch also makes cluster_unintern static, because it should be.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>