Tuetuopay <tuetuopay@me.com>: Author Summary

Builds triggered by Tuetuopay <tuetuopay@me.com>

Builds triggered by an author are those builds which contains changes committed by the author.
4
2 (50%)
2 (50%)

Breakages and fixes

Broken means the build has failed but the previous build was successful.
Fixed means that the build was successful but the previous build has failed.
0 (0% of all builds triggered)
1 (25% of all builds triggered)
1
Build Completed Code commits Tests
FRR › FRR › #1995 1 week ago
zebra: Treat ifaces withouth IPv4 as unnumbered
The current definition of an unnumberd interface as an interface with a
/32 IPv4 is too restrictive, especially for EVPN symmetric routing since
commit 2b83602b2 "*: Explicitly mark nexthop of EVPN-sourced routes as
onlink".

It removes the bypass check wether the nexthop is an EVPN VTEP, and
relies on the SVI to be unnumberd to bypass the gateway lookup. While
this works great if the SVI has an IP, it might not, and the test falls
flat and EVPN type 5 routes are not installed into the RIB.

Sample interface setup, where vxlan-blue is the L3VNI and br-blue the
SVI:

              +----------+
              |          |
              | vrf-blue |
              |          |
              +---+--+---+
                  |  |
          +-------+  +-----------+
          |                      |
     +----+----+       +---------+---------+
     |         |       |        br1        |
     | br-blue |       |    10.0.0.1/24    |
     |         |       +-+-------+-------+-+
     +----+----+         |       |       |
          |              |       |       |
    +-----+------+ +-----+--+ +--+---+ +-+----+
    |            | |        | |      | |      |
    | vxlan-blue | | vxlan1 | | eth1 | | eth2 |
    |            | |        | |      | |      |
    +------------+ +--------+ +------+ +------+

For inter-VNI routing, the SVI has no reason to have an IP, but it still
needs type-5 routes from remote VTEPs.

This commit expands the definition of an unnumberd interface to an
interface having a /32 IPv4 or no IPv4 at all.

Signed-off-by: Tuetuopay <tuetuopay@me.com>
6583 passed
FRR › RPKI › #930 1 week ago
zebra: Treat ifaces withouth IPv4 as unnumbered
The current definition of an unnumberd interface as an interface with a
/32 IPv4 is too restrictive, especially for EVPN symmetric routing since
commit 2b83602b2 "*: Explicitly mark nexthop of EVPN-sourced routes as
onlink".

It removes the bypass check wether the nexthop is an EVPN VTEP, and
relies on the SVI to be unnumberd to bypass the gateway lookup. While
this works great if the SVI has an IP, it might not, and the test falls
flat and EVPN type 5 routes are not installed into the RIB.

Sample interface setup, where vxlan-blue is the L3VNI and br-blue the
SVI:

              +----------+
              |          |
              | vrf-blue |
              |          |
              +---+--+---+
                  |  |
          +-------+  +-----------+
          |                      |
     +----+----+       +---------+---------+
     |         |       |        br1        |
     | br-blue |       |    10.0.0.1/24    |
     |         |       +-+-------+-------+-+
     +----+----+         |       |       |
          |              |       |       |
    +-----+------+ +-----+--+ +--+---+ +-+----+
    |            | |        | |      | |      |
    | vxlan-blue | | vxlan1 | | eth1 | | eth2 |
    |            | |        | |      | |      |
    +------------+ +--------+ +------+ +------+

For inter-VNI routing, the SVI has no reason to have an IP, but it still
needs type-5 routes from remote VTEPs.

This commit expands the definition of an unnumberd interface to an
interface having a /32 IPv4 or no IPv4 at all.

Signed-off-by: Tuetuopay <tuetuopay@me.com>
Testless build
You have insufficient permissions to see all of the builds.
Build Completed Code commits Tests
Build Completed Code commits Tests
You have insufficient permissions to see all of the builds.