Multi-Protocol BGP (MP-BGP) is a BGP-4 extension that enables BGP speakers to encode Network Layer Reachability Information (NLRI) of various address types, such as IPv4/6, VPNv4, and MAC addresses, into BGP Update messages. MP-BGP features an MP_REACH_NLRI Path-Attribute (PA), which utilizes an Address Family Identifier (AFI) to describe service categories. Subsequent Address Family Identifier (SAFI), in turn, defines the solution used for providing the service. For example, L2VPN (AFI 25) is a primary category for Layer-2 VPN services, and the Ethernet Virtual Private Network (EVPN: SAFI 70) provides the service. Another L2VPN service is Virtual Private LAN Service (VPLS: SAFI 65). The main differences between these two L2VPN services are that only EVPN supports active/active multihoming, has a control-plane-based MAC address learning mechanism, and operates over an IP-routed infrastructure.
EVPN utilizes various Route Types (EVPN RT) to describe the Network Layer Reachability Information (NLRI) associated with Unicast, BUM (Broadcast, Unknown unicast, and Multicast) traffic, as well as ESI Multihoming. The following sections explain how EVPN RT 2 (MAC Advertisement Route) is employed to distribute MAC and IP address information of Tenant Systems enabling the expansion of VLAN over routed infrastructure.
The Tenant System refers to a host, virtual machine, Continue reading
User interface design is notoriously bad for networking gear–but why, and what can we do about it? Frank Seesink joins Tom and Russ to talk about user interface stupidity.
FRR or (pre-NVUE) Cumulus Linux are the best bets if you want to run BGP labs in a resource-constrained environment like your laptop or a small public cloud instance. However, they both behave a bit differently from what one might expect from a networking device, including:
A new lab exercise covers these intricate details and will help you get fluent in configuring BGP on FRR or Cumulus Linux virtual machines or containers.
FRR or (pre-NVUE) Cumulus Linux are the best bets if you want to run BGP labs in a resource-constrained environment like your laptop or a small public cloud instance. However, they both behave a bit differently from what one might expect from a networking device, including:
A new lab exercise covers these intricate details and will help you get fluent in configuring BGP on FRR or Cumulus Linux virtual machines or containers.
Network engineering is not “going away.” Network engineering is not less important than it was yesterday, last year, or even a decade ago.
But there still seems to be a gap somewhere. There are fewer folks interested than we need. We need more folks who want to work as full-time network engineers, and more folks with network engineering skills diffused within the larger IT community. More of both is the right answer if we’re going to continue building large-scale systems that work. The real lack of enthusiasm for learning network engineering is hurting all of IT, not just network engineering.
How do we bridge this gap? We’re engineers. We solve problems. This seems to be a problem we might be able to solve (unlike human nature). Let’s try to solve it.
As you might have guessed, I have some ideas. These are not the only ideas in the world—feel free to think up more!
If you walk into a robotics class, even an introductory robotics class, you see people … building robots. If you walk into a coding class, even an introductory one, you see people … writing software. If you walk into a network network engineering class you Continue reading
A networking engineer with a picture-perfect implementation of a dual-homed enterprise site using BGP communities according to RFC 1998 to select primary- and backup uplinks contacted me because they experienced unacceptably long failover times.
They measured the failover times caused by the primary uplink loss and figured out it takes more than five minutes to reestablish Internet connectivity to their site.
A networking engineer with a picture-perfect implementation of a dual-homed enterprise site using BGP communities according to RFC 1998 to select primary- and backup uplinks contacted me because they experienced unacceptably long failover times.
They measured the failover times caused by the primary uplink loss and figured out it takes more than five minutes to reestablish Internet connectivity to their site.