OSPF External Routes (Type-5 LSA) Mysteries
Daniel Dib posted a number of excellent questions on Twitter, including:
While forwarding a received Type-5 LSA to other areas, why does the ABR not change the Advertising Router ID to it’s own IP address? If ABR were able to change the Advertising Router ID in the Type-5 LSA, then there would be no need for Type-4 LSA which meant less OSPF overhead on the network.
TL&DR: The current implementation of external routes in OSPF minimizes topology database size (memory utilization)
Before going to the details, try to imagine the environment in which OSPF was designed, and the problems it was solving.
Cumulus Linux NVUE: an Incomplete Data Model
A few weeks ago I described how Cumulus Linux tried to put lipstick on a pig reduce the Linux data plane configuration pains with Network Command Line Utility. NCLU is a thin shim that takes CLI arguments, translates them into FRR or ifupdown configuration syntax, and updates the configuration files (similar to what Ansible is doing with something_config modules).
Obviously that wasn’t good enough. Cumulus Linux 4.4 introduced NVIDIA User Experience1 – a full-blown configuration engine with its own data model and REST API2.
Cumulus Linux NVUE: an Incomplete Data Model
A few weeks ago I described how Cumulus Linux tried to put lipstick on a pig reduce the Linux data plane configuration pains with Network Command Line Utility. NCLU is a thin shim that takes CLI arguments, translates them into FRR or ifupdown configuration syntax, and updates the configuration files (similar to what Ansible is doing with something_config modules).
Obviously that wasn’t good enough. Cumulus Linux 4.4 introduced NVIDIA User Experience1 – a full-blown configuration engine with its own data model and REST API2.
netlab Release 1.3.2: Mikrotik RouterOS 7, Additional EVPN Platforms
The star of the netlab release 1.3.2 is Mikrotik RouterOS version 7. Stefano Sasso did a fantastic job adding support for VLANs, VRFs, OSPFv2, OSPFv3, BGP, MPLS, and MPLS/VPN, plus the libvirt box-building recipe.
Jeroen van Bemmel contributed another major PR1 adding VLANs, VRFs, VXLAN, EVPN, and OSPFv3 to Nokia SR OS.
Other platform improvements include:
netlab Release 1.3.2: Mikrotik RouterOS 7, Additional EVPN Platforms
The star of the netlab release 1.3.2 is Mikrotik RouterOS version 7. Stefano Sasso did a fantastic job adding support for VLANs, VRFs, OSPFv2, OSPFv3, BGP, MPLS, and MPLS/VPN, plus the libvirt box-building recipe.
Jeroen van Bemmel contributed another major PR1 adding VLANs, VRFs, VXLAN, EVPN, and OSPFv3 to Nokia SR OS.
Other platform improvements include:
Worth Reading: VXLAN Drops Large Packets
Ian Nightingale published an interesting story of connectivity problems he had in a VXLAN-based campus network. TL&DR: it’s always the MTU (unless it’s DNS or BGP).
The really fun part: even though large L2 segments might have magical properties (according to vendor fluff), there’s no host-to-network communication in transparent bridging, so there’s absolutely no way that the ingress VTEP could tell the host that the packet is too big. In a layer-3 network you have at least a fighting chance…
For more details, watch the Switching, Routing and Bridging part of How Networks Really Work webinar (most of it available with Free Subscription).
Worth Reading: VXLAN Drops Large Packets
Ian Nightingale published an interesting story of connectivity problems he had in a VXLAN-based campus network. TL&DR: it’s always the MTU (unless it’s DNS or BGP).
The really fun part: even though large L2 segments might have magical properties (according to vendor fluff), there’s no host-to-network communication in transparent bridging, so there’s absolutely no way that the ingress VTEP could tell the host that the packet is too big. In a layer-3 network you have at least a fighting chance…
For more details, watch the Switching, Routing and Bridging part of How Networks Really Work webinar (most of it available with Free Subscription).
Video: Traffic Filtering in the Age of IPv6
Christopher Werny covered another interesting IPv6 security topic in the hands-on part of IPv6 security webinar: traffic filtering in the age of dual-stack and IPv6-only networks, including filtering extension headers, filters on Internet uplinks, ICMPv6 filters, and address space filters.
You need Free ipSpace.net Subscription to watch the video.
Video: Traffic Filtering in the Age of IPv6
Christopher Werny covered another interesting IPv6 security topic in the hands-on part of IPv6 security webinar: traffic filtering in the age of dual-stack and IPv6-only networks, including filtering extension headers, filters on Internet uplinks, ICMPv6 filters, and address space filters.
You need Free ipSpace.net Subscription to watch the video.
More Arista EOS BGP Route Reflector Woes
Most BGP implementations I’ve worked with split the neighbor BGP configuration into two parts:
- Global configuration that creates the transport session
- Address family configuration that activates the address family across a configured transport session, and changes the parameters that affect BGP updates
AS numbers, source interfaces, peer IPv4/IPv6 addresses, and passwords clearly belong to the global neighbor configuration.
More Arista EOS BGP Route Reflector Woes
Most BGP implementations I’ve worked with split the neighbor BGP configuration into two parts:
- Global configuration that creates the transport session
- Address family configuration that activates the address family across a configured transport session and changes the parameters that affect BGP updates
AS numbers, source interfaces, peer IPv4/IPv6 addresses, and passwords clearly belong to the global neighbor configuration.
Starting with EOS release 4.29.0F, you can configure the neighbor next-hop-self option within IPv4 and IPv6 address families. Great job! Hopefully, we can consider this blog post a historical curiosity.
EVPN/MPLS Bridging Forwarding Model
Most networking engineers immediately think about VXLAN and data center switches when they hear about EVPN. While that’s the most hyped use case, EVPN standardization started in 2012 as a layer-2 VPN solution on top of MPLS transport trying to merge the best of VPLS and MPLS/VPN worlds.
If you want to understand how any technology works, and what its quirks are, you have to know how it was designed to be used. In this blog post we’ll start that journey exploring the basics of EVPN used in a simple MLPS network with three PE-routers:
Lab topology
EVPN/MPLS Bridging Forwarding Model
Most networking engineers immediately think about VXLAN and data center switches when they hear about EVPN. While that’s the most hyped use case, EVPN standardization started in 2012 as a layer-2 VPN solution on top of MPLS transport trying to merge the best of VPLS and MPLS/VPN worlds.
If you want to understand how any technology works, and what its quirks are, you have to know how it was designed to be used. In this blog post we’ll start that journey exploring the basics of EVPN used in a simple MLPS network with three PE-routers:
Lab topology
Repost: What’s Wrong with Network Automation
Responding to my Infrastructure as Code Sounds Scary blog post, Deepak Arora posted an interesting (and unfortunately way too accurate) list of challenges you might encounter when trying to introduce network automation in an enterprise environment.
He graciously allowed me to repost his thoughts on my blog.
Why don’t we agree on that :
Repost: What’s Wrong with Network Automation
Responding to my Infrastructure as Code Sounds Scary blog post, Deepak Arora posted an interesting (and unfortunately way too accurate) list of challenges you might encounter when trying to introduce network automation in an enterprise environment.
He graciously allowed me to repost his thoughts on my blog.
Why don’t we agree on that :
netlab EVPN/VXLAN Bridging Example
netlab release 1.3 introduced support for VXLAN transport with static ingress replication and EVPN control plane. Last week we replaced a VLAN trunk with VXLAN transport, now we’ll replace static ingress replication with EVPN control plane.
Lab topology
netlab EVPN/VXLAN Bridging Example
netlab release 1.3 introduced support for VXLAN transport with static ingress replication and EVPN control plane. Last week we replaced a VLAN trunk with VXLAN transport, now we’ll replace static ingress replication with EVPN control plane.
Lab topology
Worth Reading: QUIC Is Not a TCP Replacement
Bruce Davie makes an excellent point in his QUIC Is Not a TCP Replacement article – QUIC not a next-generation TCP, it’s a reliable RPC transport protocol.
What Bruce forgot to mention is that we had a production-grade RPC transport protocol for years – SCTP (Stream Control Transmission Protocol) – but it had two shortcomings:
- It wasn’t invented by the right people;
- It used a different IP protocol number and thus upset every ossified middlebox in the Internet. QUIC hides on top of UDP (because adding extra headers makes at least as much sense as junk DNA).
Worth Reading: QUIC Is Not a TCP Replacement
Bruce Davie makes an excellent point in his QUIC Is Not a TCP Replacement article – QUIC not a next-generation TCP, it’s a reliable RPC transport protocol.
What Bruce forgot to mention is that we had a production-grade RPC transport protocol for years – SCTP (Stream Control Transmission Protocol) – but it had two shortcomings:
- It wasn’t invented by the right people;
- It used a different IP protocol number and thus upset every ossified middlebox in the Internet. QUIC hides on top of UDP (because adding extra headers makes at least as much sense as junk DNA).
Worth Reading: EVPN/VXLAN with FRR on Linux Hosts
Jeroen Van Bemmel created another interesting netlab topology: EVPN/VXLAN between SR Linux fabric and FRR on Linux hosts based on his work implementing VRFs, VXLAN, and EVPN on FRR in netlab release 1.3.1.
Bonus point: he also described how to do multi-vendor interoperability testing with netlab.
If only he wouldn’t be publishing his articles on a platform that’s almost as user-data-craving as Google.