EVPN Route Types

Route Type Description RFC Route Type Explained
0 Reserved RFC 7432
1 Ethernet Auto-Discovery (A-D) route RFC 7432 EVPN Type 1 Explained
2 MAC/IP advertisement route RFC 7432 EVPN Type 2 Explained
3 Inclusive Multicast Route RFC 7432 EVPN Type 3 Explained
4 Ethernet Segment Route RFC 7432 EVPN Type 4 Explained
5 IP Prefix Route draft-ietf-bess-evpn-prefix-advertisement-04 EVPN Type 5 Explained
6 Selective Multicast Ethernet Tag Route draft-ietf-bess-evpn-igmp-mld-proxy-00 EVPN Type 6 Explained
7 IGMP Join Synch Route draft-ietf-bess-evpn-igmp-mld-proxy-00 EVPN Type 7 Explained
8 IGMP Leave Synch Route draft-ietf-bess-evpn-igmp-mld-proxy-00  EVPN Type 8 Explained
9 Per-Region I-PMSI A-D route draft-ietf-bess-evpn-bum-procedure-updates-01
10 S-PMSI A-D route draft-ietf-bess-evpn-bum-procedure-updates-01
11 Leaf A-D route draft-ietf-bess-evpn-bum-procedure-updates-01
12-255 Unassigned

 

EVPN Type 5 (IP Prefix Route) Explained

EVPN Type 5 route that is proposed in ‘IP Prefix Advertisement in EVPN’ draft is a mechanism to carry IPv4 and IPv6 advertisements in EVPN-only networks. While EVPN Type 2 routes allow to carry both MAC addresses and IP addresses, tight coupling of specific IP addresses with IP Prefixes might not be desirable. Section 2.2 of the draft discusses different scenarios where such coupling is nor desirable.

Continue reading “EVPN Type 5 (IP Prefix Route) Explained”

EVPN MPLS Service Types Illustrated

EVPN VLAN-Based Service

With this service interface, an EVPN instance consists of only a single broadcast domain (e.g., a single VLAN).  Therefore, there is a one-to-one mapping between a VID on this interface and a MAC-VRF. Since a MAC-VRF corresponds to a single VLAN, it consists of a single bridge table corresponding to that VLAN.

EVPN VLAN-Based Service
EVPN VLAN-Based Service

Click here for Juniper MX Configuration Example.

Continue reading “EVPN MPLS Service Types Illustrated”

EVPN MPLS Service Types

Broadcast Domains

(VLANs)

Bridge Table MAC VLAN to MAC-VRF Mapping Ethernet TAG ID VID Translation
VLAN-Based Service Single Single Can overlap between VLANs one-to-one 0 Egress PE
VLAN Bundle Service Multiple Single Unique for all VLANs many-to-one 0 Not Supported
Port-Based Service Multiple Single Unique for all VLAN many-to-one 0 Not Supported
VLAN-Aware Bundle Service Multiple One per VLAN Can overlap between VLANs many-to-one VID or normalized TAG ID

 

Supported
Port-Based VLAN-Aware Service Multiple One per VLAN Can overlap between VLANs many-to-one VID

 

Not Supported

For more information on EVPN, please refer to our other articles on this topic:

http://www.bgphelp.com/tag/evpn/

EVPN Type 4 (Ethernet Segment route) Explained

Ethernet Segment Routes are needed in multi-homing scenario and used for Designated Forwarder Election. Designated Forwarder is responsible for sending broadcast, unknown multicast and multicast (BUM) traffic to the CE on a particular Ethernet Segment.

RFC 7432 allows selecting a DF at the granularity of <ES, VLAN> for VLAN-based service and <ES, VLAN bundle> for VLAN-aware service. This enables load-balancing of BUM traffic at a VLAN or VLAN-bundle level.

Continue reading “EVPN Type 4 (Ethernet Segment route) Explained”

EVPN Type 3 (Inclusive Multicast Ethernet Tag route) Explained

Type 3 routes are required for Broadcast, Unknown Unicast and Multicast (BUM) traffic delivery across EVPN networks. Type 3 advertisements provide information about P-tunnels that should be used to send BUM traffic.

Without Type 3 advertisements, ingress router would not know how to deliver BUM traffic to other PE devices that comprise given EVPN instance.

Continue reading “EVPN Type 3 (Inclusive Multicast Ethernet Tag route) Explained”

EVPN Type 2 (MAC/IP Advertisement route) Explained

Type 2 routes are used to advertise MAC addresses and IP addresses that might be associated with aforementioned MAC addresses.

In order to advertise Type 2 routes, PE needs to learn MAC addresses from the directly attached CEs. This is done via normal data-plane learning mechanisms. RFC 7432 also allows for MAC address learning via control plane interaction between PE and CE, although we have not see this implemented by any vendors.

Continue reading “EVPN Type 2 (MAC/IP Advertisement route) Explained”

EVPN Type 1 (Ethernet Auto-Discovery) Explained

Type 1 advertisements are used for two distinct functions – Fast Convergence and Aliasing. EVPN Fast Convergence allows PE devices to change the next-hop adjacencies for all MAC addresses associated with a particular Ethernet Segment. EVPN aliasing allows traffic to be balanced across multiple egress points.

Type 1 routes are only advertised if Ethernet Segment Identifier is set to non-zero value, meaning that Type 1 routes are only originate for multi-homed sites.

Please refer to the following cheatsheet if you are not familiar with EVPN Terminology.

Continue reading “EVPN Type 1 (Ethernet Auto-Discovery) Explained”

BGP Best Practices or Dissecting RFC 7454

In this article, we will focus on the RFC 7547. This RFC covers BGP Operations and Security best current practices and needs to be understood and implemented by any organization running BGP in production.

Introduction

RFC 7547 recommendations can be split into the following categories:

  • BGP Session Protection
  • Prefix Filtering Recommendations
  • AS-Path Filtering Recommendations
  • Next-Hop Filtering
  • Optional BGP Community Scrubbing
  • Traffic Filtering Recommendations

In this article, we will use Roman Numerals (I, II, etc) to identify BGP protection mechanisms, Arabic Numerals (1,2, etc) to identify Traffic Filtering, Uppercase Letters (A, B, etc) to identify Prefix Filtering, and Lowercase Letter (a,b, etc) to identify AS-Path filtering and Greek  Letters (α,   β)  to identify BGP scrubbing.

Figure below shows depicts peering routers connected to upstream, private, IXP and downstream peers.

RFC7454 Peering Router
RFC7454 Peering Router

As most of the modern routers do, our sample router has a dedicated forwarding engine responsible for forwarding packets and a dedicated routing engine responsible for participating in routing protocols, building Routing Information Base (RIB) and Forwarding Information Base (FIB) tables. While actual vendors’ implementations will vary between routers’ models, best practices discussed in this article are generic enough to be applicable to the majority of vendors.

BGP Protection

Group of BGP Protection mechanisms is responsible for maintaining stability of BGP sessions, as well as providing anti-spoofing and bogus route-injection protection mechanisms. We will also add “maximum-prefix” protection mechanism to this category, as it helps to protect against operators’ mistakes.

RFC7454 BGP Protection
RFC7454 BGP Protection

I. GTSM (TTL Security)

GTSM – Generalized TTL Security Mechanisms, also known as TTL security, defined in RFC 5082. GTSM (TTL Security) is a mechanism that checks TTL value of incoming IP Packets in order to make sure they have not been spoofed. Directly connected BGP peers will set IP TTL value to 255, making it impossible to deliver spoofed IP with TTL=255 packets via non-directly connected interfaces. As per section 5.2 of RFC 7454 GTSM should be implemented.

Configuration Examples:

II. TCP-AO (TCP Authentication Option)

TCP-AO – TCP Authentication Option is a stronger protection mechanism than traditionally used MD5, it is described in RFC 5925. At some point, it is expected to replace MD5 for session protection. It has not been widely adopted due to the lack of implementation from equipment vendors.

Section 5.1 of RFC 7454 recommends, although does not require, leveraging either MD5 or TCP-AO for session protection.

No configuration examples due to lack of vendors’ implementation. 

III. MD5

MD5 – Protection of the TCP session header, described in RFC 2385. MD5 is a TCP session protection mechanism that has been available for many years and is supported by the vast majority of equipment manufacturers. It has become the de-facto standard for BGP session protection. Although it has been made obsolete by TCP-AO protection, it is still used for the majority of BGP peering sessions.

Configuration Examples (Simple Key and Key-Chains):

IV. Max-Prefix

Maximum-Prefix Limit is one of the commonly used safety mechanisms that will bring down BGP session if the number of routes advertised by the peer exceeds pre-configured limit. Section 8 of RFC 7454 provides the following recommendations:

  • From public and private peers, it is recommended to have the limit set to either a lower than the number of routes on the Internet, or to a specific number for each peer based on the advertised number of routes plus some headroom. From the author’s experience, setting the number to below the number of routes on the Internet is too risky and should be avoided. There have been situations where public and private peers would make an error and leak the entire BGP table to their peering partners, causing major network instability. Author prefers setting session reset limit to 2x the number of routes normally advertised by the peer and session warning limit to 1.5x number of routes. Your NOC should monitor logs for warning threshold violations and adjust limits accordingly.
  • From upstream, the number of routes should be set higher than the number of routes on the Internet, but not higher that the capabilities of your routers. For example, if FIB tables of your devices can support up to 1 Million IPv4 routes, you can set the limit to be 950,000 routes. While resetting BGP sessions with your upstream providers is never a good thing, damage caused by reset is much lower than that caused by FIB exhaustion. For more information, please refer to our article on BGP Table Size analysis (http://www.bgphelp.com/2017/01/01/bgpsize/).

MD5, TCP-AO and GTSM have to be configured on both sides of the BGP session. Max-Prefix can be configured on one side only.

Prefix Filtering

Prefix-filtering policies are responsible for discarding bogus route-advertisements to and from BGP peers. Examples of these bogus advertisements are prefixes from RFC1918 address space, to specific routes (>24), unallocated prefixes.

RFC7454 Prefix Filtering
RFC7454 Prefix Filtering

Route-filtering should be implemented on each BGP session maintained by the service provider:

  • A. Private/Public/Transit Inbound Prefix Filtering
  • B. Private/Public/Transit Outbound Prefix Filtering
  • C. Downstream Inbound Prefix Filtering
  • D. Downstream Outbound Prefix Filtering

A. Inbound Prefix Filtering from Private/Public/Transit Peers

RFC 7475 provides similar recommendations for route filtering from Upstream Providers (section 6.2.3) and route-filtering from private and public peers (section 6.2.1). Because of this, there is very little difference in filtering policies, allowing us to combine them in one recommendation.

As per Section 6.2.1.1.1 of RFC 7475, the following prefixes should not be accepted from peers

  • Special-Purpose Prefixes (RFC 7475 Section 6.1.1)
  • Unallocated Prefixes (RFC 7475 Section 6.1.2)
  • Prefixes that are too specific (RFC 7475 Section 6.1.3)
  • Prefixes belonging to the local AS (RFC 7475 Section 6.1.4)
  • IXP LAN Prefixes (RFC 7475 Section 6.1.5), other than authorized ASes (RFC 7475 Section 6.1.5)
  • The Default Route (RFC 7475 Section 6.1.6)

Section 6.2.1.1.2 of RFC 7475 also provides recommendations for “Strict” inbound filtering option, which we consider to be too risky and will not cover in this document.

B. Outbound Prefix Filtering towards Private/Public/Transit Peers

As per Section 6.2.1.2 of RFC 7475, the following prefixes should not be accepted from peers

  • Special-Purpose Prefixes (RFC 7475 Section 6.1.1)
  • Prefixes that are too specific (RFC 7475 Section 6.1.3)
  • IXP LAN Prefixes (RFC 7475 Section 6.1.5)
  • The Default Route (RFC 7475 Section 6.1.6)

You also need to make sure that only authorized prefixes (those advertised by your AS and downstream customers) are being sent.

C. Inbound Prefix Filtering from Customers

General recommendations provided in Section 6.2.2.1 of RFC 7475 state that “only customer prefixes SHOULD be accepted, all others SHOULD be discarded.” The list of allowed prefixes should be manually built by the network provisioner after validating that customer prefixes are indeed allocated to the client by IP address management authorities.

In some cases, if customer advertises too many prefixes or has BGP clients of their own, customer-specific filters can be replaced with generic filters previously described in “Inbound Filtering from Private/Public/Transit Peers” section of the paper.

D. Outbound Prefix Filtering towards Customers

Depending on the customer preferences, they might want to receive

  • The default route only
  • Full Internet routing table
  • Subset of the Full Internet table (e.g. only the routes received via public and private peers, but not the transit routes)
  • The default route in addition to the Full or Partial Internet view

Generic recommendation described in Section 6.2.2.2 of RFC 7454 states that the following prefixes should not be sent to the customer:

  • Special-Purpose Prefixes (RFC 7475 Section 6.1.1)
  • Prefixes that are too specific (RFC 7475 Section 6.1.3)
  • The Default Route (RFC 7475 Section 6.1.6), for those customers not willing to receive it

AS-Path Filtering

Section 9 of RFC 7454 provides a number of AS-Path Filtering recommendations that should be implemented on upstream/private/public peering sessions and customer sessions.

RFC7454 AS Path Filtering
RFC7454 AS Path Filtering

Similar to how we analyzed Prefix Filtering recommendations in the previous chapter, we will review AS-Path Filtering recommendations below.

a. Inbound AS-Path Filtering from Private/Public/Transit Peers

Section 9 of RFC 7454 recommends the following:

  • Private AS numbers should not be accepted, unless used for special purposes such as black-hole origination
  • AS Paths with the first AS number not the one of the peer should not be accepted, unless originated by IXP’s router server
  • Do not accept your own AS number in the AS path

b. Outbound AS-Path Filtering from Private/Public/Transit Peers

Section 9 of RFC 7454 recommends the following:

  • Do not originate prefixes with nonempty AS Paths, unless you intend to provide transit for these prefixes
  • Do not originate prefixes with upstream AS numbers in the AS Path, unless you intend to provide transit to these prefixes
  • Do not advertise Private AS Paths, unless there is a special “private” arrangement with your peers

c. Inbound AS-Path Filtering from Downstream Customers

Section 9 of RFC 7454 recommends the following:

  • Only accept 2-byte and 4-byte AS paths containing ASNs belonging to the customer.
  • If this is not possible, accept only path lengths relevant to the type of the customer, while discourage excessive prepending
  • Do not accept your own AS number in the AS path

d. Outbound AS-Path Filtering from Downstream Customers

  • Do not advertise Private AS Paths, unless there is a special “private” arrangement with your customers

Next-Hop Filtering

BGP can advertise prefixes with a third-party next hop, thus directing packets not to the peer announcing the prefix but somewhere else. This mechanism is commonly used at Internet Exchange Points, where prefixes will be announced by IXP’s route-server.

RFC7454 Next Hop Filtering
RFC7454 Next Hop Filtering

Section 10 of RFC 7545 recommends the following policies at IXP locations:

  • For direct peering (without router-server), apply inbound BGP policy that would set next-hop for the accepted prefix to BGP peer IP address
  • For indirect peering (with IXP’s route-server), accept next-hop attribute advertised by the route-server

BGP Community Scrubbing

Section 11 of RFC 7454 provides the following optional community scrubbing recommendations.

RFC7454 BGP Community Scrubbing
RFC7454 BGP Community Scrubbing
  • Ingress BGP peering policy applied to transit/public/private and downstream peers should remove all inbound communities with SP’s number in the high-order bits, except for the ones used for signaling (e.g. setting BGP Local Preference).
  • Ingress BGP Policy should not remove other communities, as those communities can be used to communicate with upstream providers.

Traffic Filtering

Section 4 of RFC 7454 provides basic recommendations when it comes to traffic filtering and BGP.

RFC7454 Traffic Filtering
RFC7454 Traffic Filtering

 

All packets destined to TCP Port 179 and not originated from addresses of configured BGP peers should be discarded. If supported, Control Plane ACL (point 3 on the diagram) should be used. If not supported, ACL applied to each peer-facing port (point 1) should be used.

If supported, BGP Rate-Limiting (point 4) should also be implemented, to make sure that the number of BGP packets per second does not exceed platform’s capability.

Generic Control Plane protection recommendations are out of RFC 7454 scope and are covered in RFC 6192.