DHCP Relay in VxLAN BGP EVPN

Do you really need to make any special configurations when you implement VxLAN EVPN and you need to configure DHCP Relay? All Cisco's guides say you do..but as I found out recently it's not exactly like that. I'm going to address several scenarios here so we'll find out where we need special tweaks for DHCP Relay to work and where we don't. All tested on a real N9Ks + NX-OSv.

When Default Config Is Fine

Every Cisco's guide on this topic starts with saying that he challenge initially is that every Leaf has the same anycast gateway configured, so we can't really use this address as source address for relay and we need unique address (such as loopback). In fact, there's nothing stopping from using non-unique address as source. Personally I think there's still more convenient to use unique address wherever it's possible and it's certainly how I recommend to have it done - for several reasons like troubleshooting and security, but still, there is a possibility to make it work another way. Also keep in mind using unique address is the only recommended validated design by Cisco. Still, this configuration works as well, so if you can't use unique addresses for some reason (like you're in the middle of migration to your new fancy VxLAN EVPN fabric and you suddenly realize all your DHCP servers are running Windows Server 2012 (which will require a several kilometers (depending of your fabric size) of a duct tape to work with new DHCP options for EVPN which are a must if you use unique loopback addresses) this might be a way to go.

So, in this part we're going to consider scenario where you are fine with using non-unique Anycast Gateway address as source address.
How will response packet be routed back to the correct Leaf? Let's consider these possible scenarios:

1. DHCP Server is external network located somewhere behind BGW. BGW is a L3 only, so there's no L2 VNIs configured on it, only L3 VNIs for Routing. We assume client and server are within the same VRF.

Demystifying BFD intervals

If I was to make a list of most wide-used and still very poorly-documented protocols, I'd definitely put BFD in it. In this post I'll try to answer several questions I was looking answers for.

TLDR: by default when you enable BFD there's both Echo and Asynchronous BFD modes running simultaneously (so there's two different types of packets your devices exchange with each other). The one's responsible for failure detection is Echo Mode and it's the one you are configuring intervals and multipliers for. In outputs you'll also see intervals for Asynchronous Mode packets which are significantly higher but you don't have to worry because Echo Mode packets are used for failure detection.

Let's say you configured BFD as follows (I'm using CSR1000V with IOS XE 16.04.03 for this example):

interface GigabitEthernet2
<...>
 bfd interval 50 min_rx 50 multiplier 3
!
router ospf 1
 bfd all-interfaces

So we're all good, setting our timers for minimal possible values. But when you start to check things out, you see this:

Core3#sh bfd nei details 

IPv4 Sessions
NeighAddr                              LD/RD         RH/RS     State     Int
10.30.1.30                           4097/4097       Up        Up        Gi2
Session state is UP and using echo function with 50 ms interval.
Session Host: Software
OurAddr: 10.30.1.29     
Handle: 1
Local Diag: 0, Demand mode: 0, Poll bit: 0
MinTxInt: 1000000, MinRxInt: 1000000, Multiplier: 3
Received MinRxInt: 1000000, Received Multiplier: 3
Holddown (hits): 0(0), Hello (hits): 1000(1590)
Rx Count: 1587, Rx Interval (ms) min/max/avg: 2/1003/875 last: 358 ms ago
Tx Count: 1594, Tx Interval (ms) min/max/avg: 2/1004/871 last: 315 ms ago
Elapsed time watermarks: 0 0 (last: 0)
Registered protocols: OSPF CEF 
Uptime: 00:23:09
Last packet: Version: 1                  - Diagnostic: 0
             State bit: Up               - Demand bit: 0
             Poll bit: 0                 - Final bit: 0
             C bit: 0                                   
             Multiplier: 3               - Length: 24
             My Discr.: 4097             - Your Discr.: 4097
             Min tx interval: 1000000    - Min rx interval: 1000000
             Min Echo interval: 50000  

What's this? Why do we have Rx/TxInt of 1 second? And what's echo? OK, let's figure out how exactly BFD works.

IPv6 Lab: ISP & Client Side using Linux and Cisco

So I got really tired of reading about some basic IPv6  stuff and then forgetting it in a couple of months due to lack of practice and decided to set up a lab, which will contain both ISP and client sides.
This is what my topology will look like:

Components used:

• Client_PC: Linux box with Ubuntu Server 18.04 installed with rdnssd (which is required to receive list of DNS servers via RA);
• Home_Router: Linux box with Ubuntu Server 18.04 installed with wide-dhcpv6-client and radvd. (I had to install wide-dhcpv6-client, cause isc-dhcp-client, which comes by default, barely has any decent documentation and I wasn't even able to find out if it supports some of the features we're going to use in this lab);
• ISP_R1: Cisco C7200 15.2(4)S6. It's used as DHCPv6 server as well.

How I'm going to assign IPv6 addresses to devices (I'll cover the details of different ways to achieve this further)

• Client_PC: no DHCPv6 at all, only Stateless Address Autoconfiguration
• Home_Router: DHCPv6.

PPP LCP Keepalives & Troubleshooting it on Junos

Until the last week I had quite vague understanding of how LCP keepalives work - it was just one of those underlying protocols you have general knowledge about but never really go in details with. However, last week I encountered a problem that required slightly deeper understanding of how it works, and since some of the important details are not emphasized in the sources I read, I decided to write a short note on this topic.

So, how does it work? Let's take a look on a capture taken between a PPPoE server and a Linux client:

IPv6 Free Core: Configuring IPv6 Labeled Unicast on Juniper MX

Here's just a short note on IPv6 Labeled Unicast - an elegant solution to the case where you need to connect two IPv6 sites through your IPv4-only network. (The other option would, of course, be to enable IPv6 on all of your core routers, which is not always convenient).

So here I'm going to show you the minimal configuration to get this lab up and running, a trick that would make the configuration more optimal and elegant (why would you need "explicit-null"?), and take a quick look on what's going on behind the scene.

That's what my topology looks like:

Configuring CoA: Juniper MX + FreeRADIUS

Recently I had to configure CoA on Juniper and was surprised by how vague the coverage of this topic is. Juniper's Day One on CoA is not bad, however, in my opinion, sometimes it's focusing on unnecessary details while missing the important ones.

As you probably already know, CoA, or Change of Authorization allows you to modify subscribers sessions "on the flight", without having to disrupt the session. CoA is usually used together with some kind of billing software, so you can implement all kinds of things - for example, implement time-scheduled rate-limiting (imagine, for example, that you as ISP provide a tariff that allows unlimited speed at particular hours and lower speeds at all other time), or abrupting internet access as soon as there's no money left on client's account...and so on.


My topology is as simple as possible and looks like this:

The Curious Case Of OSPF NSSA LSA on GRE Tunnel

Today I encountered a case which is really easy when you know what exactly to look for but seems puzzling at the first glance.

This is what our topology looks like:

We have two routers connecting two locations with OSPF configured on each. The primary connection is via GRE tunnel while backup connection is just a direct connection (say we have dark fiber or L2VPN between these locations). OSPF neighbor relations are established on both links.

Nodes exchange routes between each other and everything goes on just fine..until the primary connection goes down. Then some of the routes R2 sends to R1 are seen on R1 as connected via the backup link..and some are still seen as connected via tunnel interface, though OSPF neighbor is already considered dead on this link.

Sounds intriguing?