EVPN+BGP+VXLAN between JunOS and FRR (with Cumulus)

Recently I was asked to assist with setting up a BGP+EVPN+VXLAN network where Juniper MX204 routers would be the gateways in the VNI and the rest of the network would consist of Spine and Leaf switches running Cumulus Linux.

The actual workload would run on Proxmox servers which would also run Frrouting. I wrote a post about this earlier.

I’ll make this a short post as you are probably reading this to find a solution to your problem, I’ll make it short and post the configuration.

Interoperability

BGP and EVPN are standardised protocols and they should work between vendors. EVPN is however still fairly new and vendors sometimes implement features differently.

I noticed this with the route-targets/communities set by FRR and JunOS for EVPN routes. These would not match and thus JunOS and FRR would not learn eachothers EVPN routes.

Solution / Configuration

In this case the solution was to set the route-target/community/vrf-target for all EVPN routes (and thus VNI) to 100:100 (something I chose).

JunOS

wido@juniper-mx204> show configuration routing-instances evpn 
instance-type virtual-switch;
protocols {
    evpn {
        encapsulation vxlan;
        extended-vni-list all;
        multicast-mode ingress-replication;
    }
}
vtep-source-interface lo0.0;
bridge-domains {
    v1500 {
        vlan-id none;
        routing-interface irb.1500;
        vxlan {
            vni 1500;
            ingress-node-replication;
        }
    }
    v1501 {
        vlan-id none;
        routing-interface irb.1501;
        vxlan {
            vni 1501;
            ingress-node-replication;
        }
    }
}
route-distinguisher 10.255.0.1:100;
vrf-target target:100:100;

wido@juniper-mx204>

frrouting

router bgp 65118
 no bgp ebgp-requires-policy
 no bgp default ipv4-unicast
 no bgp network import-check
 neighbor upstream peer-group
 neighbor upstream remote-as external
 neighbor enp129s0f0np0 interface peer-group upstream
 neighbor enp129s0f1np1 interface peer-group upstream
 !
 address-family ipv4 unicast
  network 10.255.0.17/32
  neighbor upstream activate
 exit-address-family
 !
 address-family ipv6 unicast
  network 28xx:xxx::17/128
  neighbor upstream activate
 exit-address-family
 !
 address-family l2vpn evpn
  neighbor upstream activate
  advertise-all-vni
  vni 1500
   route-target import 100:100
   route-target export 100:100
  exit-vni
  vni 1499
   route-target import 100:100
   route-target export 100:100
  exit-vni
  vni 1498
   route-target import 100:100
   route-target export 100:100
  exit-vni
  advertise-svi-ip
 exit-address-family
exit

This now resulted in JunOS and Frr learning the EVPN routes and this then also showed in the EVPN database of JunOS. The VMs in Proxmox were now able to reach the internet!

wido@juniper-mx204> show evpn database l2-domain-id 1500 
Instance: evpn
VLAN  DomainId  MAC address        Active source                  Timestamp        IP address
     1500       00:00:5e:00:01:01  05:00:00:fd:e9:00:00:05:dc:00  May 22 06:57:59  xx.124.220.3
     1500       00:00:5e:00:02:01  05:00:00:fd:e9:00:00:05:dc:00  May 22 06:57:59  xx:xx:2::3
     1500       46:50:13:6d:5d:bb  10.255.0.17                    May 23 05:44:20
     1500       74:e7:98:30:8c:e0  irb.1500                       May 18 06:29:04  xx.124.220.1
                                                                                   xx:xx:2::1
                                                                                   fe80::76e7:9805:dc30:8ce0
     1500       80:db:17:eb:d5:d0  10.255.0.2                     May 22 06:57:59  xx.124.220.2
                                                                                   xx:xx:2::2
                                                                                   fe80::82db:1705:dceb:d5d0
     1500       9a:9a:94:80:1a:3a  10.255.0.17                    May 23 06:02:25
     1500       ca:f0:03:fe:d6:dd  10.255.0.17                    May 22 18:18:43
     1500       f6:db:10:b6:5b:c4  10.255.0.17                    May 23 05:58:39  xx.124.220.6

wido@juniper-mx204> 

Combined Charging System (CCS) and IPv6

When we talk about IP protocols and IPv6 in this particular case we think about routing over the internet. But what many do not know is that IPv6 is already playing a major role in all kinds of systems.

In this post I’m not going to explain IPv6 in detail, for many things I’ll link to external pages.

Ad-Hoc networking using Link-Local

IPv6 has a great feature where each host on a network will generate a Link Local Address (LL) which is mandatory according to the protocol.

The great thing about LL is that it allows hosts to establish communication without the need of DHCP or anything else. Just plug in a host on a Layer 2 Ethernet network and they can start communicating right away.

fe80::5054:ff:fe98:aaee is an example of a IPv6 LL address and using this address it can search for (via multicast) and communicate with other hosts in the network.

Examples of systems using IPv6 LL are Matter and Combined Charging System (CCS).

Combined Charging System (CCS)

CCS is a standard for (fast charging) electric vehicles. Some years ago I stumbled upon multiple documents showing that CCS would be using a combination of PLC, IPv6, TCP/IP, UDP, HTTP, TLS and many other very common protocols for communication.

Using PowerLine Communication (PLC) the vehicle and charger will establish a Layer 2 Ethernet network over which they will communicate using IPv6 LL.

I was not able to find the exact details of the IPv6 part of the CCS standard, but it is very interesting to see that IPv6 is being used for something like charging electric vehicles.

Kudos to the people behind CCS and for using IPv6 for this!

In my opinion it’s a no-brainer to use IPv6 for such functionality as the LL addressing allow you to create networks very quickly and in a reliable manner.

You can also use a very well documented protocol and the many tools for IPv6.

Now I would like to run Wireshark on such a link!

If you have more information about this, please contact me!

Babycam using a Unifi G3 camera

It’s been almost a year that I’ve been living in my new house and proud father of a son.

Almost every parent wants to watch their little on through a camera to see them sleeping in their bed.

There are many, many, many baby monitors on the market but in my experience they are all crap. Our house is build with a lot of concrete and none of them was able to penetrate the walls in our house and thus have a reliable video connection.

I also tried some IP/WiFi based baby monitors from for example Foscam, but these are all cheap Chinese cameras and didn’t work either. Crashing iPad apps, sending random (UDP) packets to China, half-baked UIs, etc, etc. They were all very low quality.

After a lot of frustrating I bought a Unifi Video G3 (UVC-G3-BULLET) camera and mounted it on the bed of my son.

Unifi Video G3 camera mounted on baby bed

I am using multiple Unifi video cameras around my house using Unifi Video, so for me it was just a matter of adding an additional camera to my Unifi system.

Video camera in Unifi Video

RTMP + HLS with Nginx

I also experimented with building a video stream using RTMP, ffmpeg and HLS with Nginx.

The Unifi cameras can export a RTSP stream which you can set up to live stream with Nginx. I tried this and it works for me, but with a delay of ~20s I thought it was not usable on my use-case.

It does however allow for a very easy way of building your own webcam!