<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-text-flowed"
      style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode">On
      5/11/2025 2:57 am, Ondrej Zajicek wrote:
      <br>
      <blockquote type="cite" style="color: #007cff;">On Tue, Nov 04,
        2025 at 09:48:29PM +1100, William via Bird-users wrote:
        <br>
        <blockquote type="cite" style="color: #007cff;">Hi Ondrej,
          <br>
          <br>
          Apologies on the delay, I'm testing when I have the brain
          space and my lab
          <br>
          is powered up.
          <br>
        </blockquote>
        Hi
        <br>
        <br>
        Thanks for your feedback!
        <br>
      </blockquote>
      Always glad to be able to contribute back in some way ðŸ™‚
      <br>
      <blockquote type="cite" style="color: #007cff;">The "encapsulation
        vxlan" stanza is just for encompassing
        <br>
        encapsulation-specific options, to future-proof for possible
        <br>
        implementations of multiple encapsulations, but that should not
        matter
        <br>
        now.
        <br>
        <br>
        Note that 'oz-evpn' is the main EVPN branch, while 'evpn' is
        more-less an old
        <br>
        snapshot.
        <br>
        <br>
        There are some more changes in 'oz-evpn', like fix for
        BGP_PMSI_TUNNEL attribute
        <br>
        flags (that is used in IMET routes) or announcing encapsulation
        extended communities.
        <br>
      </blockquote>
      The documentation is missing a chunk about the encapsulation, but
      I also had to resort to config.Y to find the VLAN definition
      block.
      <br>
      <br>
      Adding vni <vni>; to the main protocol config breaks it, but
      works fine in the vlan <vid> block.  Still needed vid
      <vid> in the main protocol config though.  See attached
      working config for reference.
      <br>
      <blockquote type="cite" style="color: #007cff;">
        <br>
        <blockquote type="cite" style="color: #007cff;">I've got mac-ip
          and imet routes floating around now, but the next issue is
          <br>
          that the wrong next-hop is being set on the imet (and mac-ip)
          routes.
          <br>
        </blockquote>
        Seems like a deviation on our side. EVPN protocol does not
        attach the
        <br>
        bgp_next_hop attribute, and such attribute is attached by BGP
        when
        <br>
        announced to BGP neighbor, based on BGP session endpoint
        address.
        <br>
        <br>
        We should fix that, meanwhile you can workaround it by setting
        'next hop address'
        <br>
        BGP channel option (in BGP EVPN channel) to the VNI address:
        <br>
        <br>
        <a class="moz-txt-link-freetext"
href="https://bird.nic.cz/doc/bird-2.17.2.html#bgp-next-hop-address">https://bird.nic.cz/doc/bird-2.17.2.html#bgp-next-hop-address</a>
        <br>
      </blockquote>
      Did that as part of the evpn stanza in the EVPN BGP chunk and it
      worked a treat! (See attached config)
      <br>
      <br>
      <blockquote type="cite" style="color: #007cff;">
        <br>
        <blockquote type="cite" style="color: #007cff;">Here's the evpn
          protocol definition:
          <br>
          protocol evpn {
          <br>
          Â Â Â Â Â Â Â Â  eth {
          <br>
          Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â  table etab;
          <br>
          Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â  import all;
          <br>
          Â Â Â Â Â Â Â Â  };
          <br>
          Â Â Â Â Â Â Â Â  evpn { };
          <br>
          Â Â Â Â Â Â Â Â  rd 1005001:10040;
          <br>
          Â Â Â Â Â Â Â Â  import target (rt, 1004001, 10040);
          <br>
          Â Â Â Â Â Â Â Â  import target (rt, 1004003, 10040);
          <br>
          Â Â Â Â Â Â Â Â  export target (rt, 1005001, 10040);
          <br>
        </blockquote>
        Note that setting multiple 'import target' options just replace
        the previous ones with the last one.
        <br>
        <br>
        You need to use a set syntax:
        <br>
        <br>
        Â Â Â Â Â Â Â Â  import target [(rt, 1004001, 10040), (rt, 1004003,
        10040)];
        <br>
        <br>
        That is likely a bit confusing and at least should generate a
        warning.
        <br>
      </blockquote>
      That worked it a lot better :D
      <br>
      <blockquote type="cite" style="color: #007cff;">
        <br>
        <blockquote type="cite" style="color: #007cff;">For what it's
          worth, 'bridge vlan add dev vxlan100 vid 40 tunnel_info id 40'
          <br>
          errors out.  The readme on
          <br>
          <a class="moz-txt-link-freetext"
href="https://gitlab.nic.cz/labs/bird-tools/-/tree/master/netlab/cf-evpn-bgp">https://gitlab.nic.cz/labs/bird-tools/-/tree/master/netlab/cf-evpn-bgp</a>
          has
          <br>
          typos in the commands too.
          <br>
        </blockquote>
        You mean typo del->add ?
        <br>
        <br>
        instead of:  bridge vlan del dev $TUNNEL vid $VID tunnel_info id
        $VNI
        <br>
        should be:   bridge vlan add dev $TUNNEL vid $VID tunnel_info id
        $VNI
        <br>
        <br>
        Note that with the latest 'oz-evpn' branch, BIRD configures
        VLANs on
        <br>
        VXLAN device automatically, but currently only for tagged vlans
        <br>
        (as in <a class="moz-txt-link-freetext"
href="https://gitlab.nic.cz/labs/bird-tools/-/blob/master/netlab/cf-evpn-bgp-tags/bird_m12.conf">https://gitlab.nic.cz/labs/bird-tools/-/blob/master/netlab/cf-evpn-bgp-tags/bird_m12.conf</a>
        )
        <br>
        <br>
      </blockquote>
      That was correct, del needed to be changed to add.
      <br>
      I also found that bridge(8) won't let you set the tunnel info
      without the VLAN being defined first.
      <br>
      <br>
      While everything <b class="moz-txt-star"><span
          class="moz-txt-tag">*</span>nearly<span class="moz-txt-tag">*</span></b>
      worked, after a couple of weeks I managed to work out that the
      bridge FDB entry that was being added was missing the source IP
      definition.  As a result the packet that entered the vxlan
      interface wasn't being forwarded upstream:
      <br>
      <br>
      root@dc1-acc-1-deb:~# bridge fdb | grep vxlan
      <br>
      00:50:00:00:12:01 dev vxlan100 vlan 40 extern_learn master br1
      <br>
      42:a5:d1:11:88:4b dev vxlan100 vlan 40 master br1 permanent
      <br>
      42:a5:d1:11:88:4b dev vxlan100 master br1 permanent
      <br>
      00:00:00:00:00:00 dev vxlan100 dst 2001:db8:ffff:1ad::401 vni
      10040 self extern_learn permanent
      <br>
      00:50:00:00:12:01 dev vxlan100 dst 2001:db8:ffff:1ad::401 vni
      10040 self extern_learn permanent
      <br>
      root@dc1-acc-1-deb:~# bridge fdb add 00:50:00:00:13:01 dev
      vxlan100 vni 10040 dst 2001:db8:ffff:1ad::401 via vxlan100 src_vni
      10040
      <br>
      root@dc1-acc-1-deb:~# bridge fdb add 00:50:00:00:12:01 dev
      vxlan100 vni 10040 dst 2001:db8:ffff:1ad::401 via vxlan100 src_vni
      10040
      <br>
      root@dc1-acc-1-deb:~#
      <br>
      <br>
      With this in place it worked a treat:
      <br>
      root@dc1-acc-1-deb:~# bridge fdb | grep vxlan
      <br>
      00:50:00:00:12:01 dev vxlan100 vlan 40 extern_learn master br1
      <br>
      42:a5:d1:11:88:4b dev vxlan100 vlan 40 master br1 permanent
      <br>
      42:a5:d1:11:88:4b dev vxlan100 master br1 permanent
      <br>
      00:50:00:00:12:01 dev vxlan100 dst 2001:db8:ffff:1ad::401 vni
      10040 src_vni 10040 via vxlan100 self permanent
      <br>
      00:00:00:00:00:00 dev vxlan100 dst 2001:db8:ffff:1ad::401 vni
      10040 self extern_learn permanent
      <br>
      00:50:00:00:13:01 dev vxlan100 dst 2001:db8:ffff:1ad::401 vni
      10040 src_vni 10040 via vxlan100 self permanent
      <br>
      00:50:00:00:12:01 dev vxlan100 dst 2001:db8:ffff:1ad::401 vni
      10040 self extern_learn permanent
      <br>
      root@dc1-acc-1-deb:~#
      <br>
      <br>
      can happily ping and throw traffic around now.  Haven't tried with
      extra VLANs/VNI's but I think it will be ok.
      <br>
      <br>
      Probably worthy of another email, but bird segfaulted when br1
      vanished (e.g. ip link delete br1).  I had noticed it previously
      when playing around, just replicated it for good measure.
      <br>
      <br>
      2025-12-25T21:17:56.421191+11:00 dc1-acc-1-deb kernel: bird[1353]:
      segfault at 10 ip 00007f1c94833d6a sp 00007fff73a44ec8 error 4 in
      libc.so.6[182d6a,7f1c946d9000+165000] likely on CPU 2 (core 0,
      socket 2)
      <br>
      2025-12-25T21:17:56.421193+11:00 dc1-acc-1-deb kernel: Code: 8b 04
      82 29 c8 c3 66 2e 0f 1f 84 00 00 00 00 00 89 f1 89 f8 48 83 e1 3f
      48 83 e0 3f 83 f9 30 77 3f 83 f8 30 77 3a f3 0f 6f 0f <f3>
      0f 6f 16 66 0f ef c0 66 0f 74 c1 66 0f 74 ca 66 0f f8 c8 66 0f
      <br>
      <br>
      Merry Christmas, more work! :D
      <br>
      <br>
      Regards,
      <br>
      William<br>
    </div>
  <div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br /><table style="border-top: 1px solid #D3D4DE;"><tr><td style="width: 55px; padding-top: 13px;"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank"><img src="https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;"/></a></td><td style="width: 470px; padding-top: 12px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Virus-free.<a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank" style="color: #4453ea;">www.avast.com</a></td></tr></table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"> </a></div></body>
</html>