-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathDesign-Proxy-ARP-ND-for-EVPN-Networks
188 lines (137 loc) · 7.84 KB
/
Design-Proxy-ARP-ND-for-EVPN-Networks
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
1. Problem Statement:
The EVPN MAC/IP Advertisement route can optionally carry IPv4 and
IPv6 addresses associated with a MAC address. Remote PEs can use this
information to reply locally (act as proxy) to IPv4 ARP requests and
IPv6 Neighbor Solicitation messages (or 'unicast-forward' them to the
owner of the MAC) and reduce/suppress the flooding produced by the
Address Resolution procedure. This EVPN capability is extremely
useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with
large broadcast domains, where the amount of ARP/ND flooded traffic
causes issues on routers and CEs. This document describes how the
EVPN Proxy-ARP/ND function may be implemented to help IXPs and other
operators deal with the issues derived from Address Resolution in
large broadcast domains.
2. Objective:
The DC Use-Case :
As described in [RFC6820] the IPv4 and IPv6 Address Resolution can
create a lot of issues in large DCs. In particular, the issues
created by the IPv4 Address Resolution Protocol procedures may be
significant.
On one hand, ARP Requests use broadcast MAC addresses, therefore any
Tenant System in a large Broadcast Domain will see a large amount of
ARP traffic, which is not addressed to most of the receivers.
On the other hand, the flooding issue becomes even worse if some
Tenant Systems disappear from the broadcast domain, since some
implementations will persistently retry sending ARP Requests. As
[RFC6820] states, there are no clear requirements for retransmitting
ARP Requests in the absence of replies, hence an implementation may
choose to keep retrying endlessly even if there are no replies.
The amount of flooding that Address Resolution creates can be
mitigated with the use of EVPN and its Proxy-ARP/ND function.
3. Solution:
o Solution Requirements
The distributed EVPN Proxy-ARP/ND function described in this document
meets the following requirements:
o The solution supports the learning of the CE IP->MAC entries on the
EVPN PEs via the management, control or data planes. An
implementation should allow to intentionally enable or disable
those possible learning mechanisms.
o The solution may suppress completely the flooding of the ARP/ND
messages in the EVPN network, assuming that all the CE IP->MAC
addresses local to the PEs are known or provisioned on the PEs from
a management system. Note that in this case, the unknown unicast
flooded traffic can also be suppressed, since all the expected
unicast traffic will be destined to known MAC addresses in the PE
BDs.
o The solution reduces significantly the flooding of the ARP/ND
messages in the EVPN network, assuming that some or all the CE
IP->MAC addresses are learned on the data plane by snooping ARP/ND
messages issued by the CEs.
o The solution provides a way to refresh periodically the CE IP->MAC
entries learned through the data plane, so that the IP->MAC entries
are not withdrawn by EVPN when they age out unless the CE is not
active anymore. This option helps reducing the EVPN control plane
overhead in a network with active CEs that do not send packets
frequently.
o The solution provides a mechanism to detect duplicate IP addresses.
In case of duplication, the detecting PE should not reply to
requests for the duplicate IP. Instead, the PE should alert the
operator and may optionally prevent any other CE from sending
traffic to the duplicate IP.
o The solution should not change any existing behavior in the CEs
connected to the EVPN PEs.
o Solution Description
Figure 1 illustrates an example EVPN network where the Proxy-ARP/ND
function is enabled.
BD1
Proxy-ARP/ND
+------------+
IP1/M1 +----------------------------+ |IP1->M1 EVPN|
GARP --->Proxy-ARP/ND | |IP2->M2 EVPN|
+---+ +----+---+ RT2(IP1/M1) | |IP3->M3 sta |
|CE1+------+ BD1 | ------> +------+---|IP4->M4 dyn |
+---+ +--------+ | +------------+
PE1 | +--------+ Who has IP1?
| EVPN | | BD1 | <----- +---+
| EVI1 | | | | |CE3|
IP2/M2 | | | | -----> +---+
GARP --->Proxy-ARP/ND | +--------+ | IP1->M1
+---+ +--------+ RT2(IP2/M2) | |
|CE2+----+ BD1 | ------> +--------------+
+---+ +--------+ PE3| +---+
PE2 | +----+CE4|
+----------------------------+ +---+
<---IP4/M4 GARP
Figure 1 Proxy-ARP/ND network example
When the Proxy-ARP/ND function is enabled in a BD (Broadcast Domain)
of the EVPN PEs, each PE creates a Proxy table specific to that BD
that can contain three types of Proxy-ARP/ND entries:
a) Dynamic entries: learned by snooping CE's ARP and ND messages. For
instance, IP4->M4 in Figure 1.
b) Static entries: provisioned on the PE by the management system.
For instance, IP3->M3 in Figure 1.
c) EVPN-learned entries: learned from the IP/MAC information encoded
in the received RT2's coming from remote PEs. For instance, IP1->M1 and IP2->M2 in Figure 1.
As a high level example, the operation of the EVPN Proxy-ARP/ND
function in the network of Figure 1 is described below. In this
example we assume IP1, IP2 and IP3 are IPv4 addresses:
1. Proxy-ARP/ND is enabled in BD1 of PE1, PE2 and PE3.
2. The PEs start adding dynamic, static and EVPN-learned entries to
their Proxy tables:
a. PE3 adds IP1->M1 and IP2->M2 based on the EVPN routes received
from PE1 and PE2. Those entries were previously learned as
dynamic entries in PE1 and PE2 respectively, and advertised in
BGP EVPN.
b. PE3 adds IP4->M4 as dynamic. This entry is learned by snooping
the corresponding ARP messages sent by CE4.
c. An operator also provisions the static entry IP3->M3.
3. When CE3 sends an ARP Request asking for the MAC address of IP1,
PE3 will:
a. Intercept the ARP Request and perform a Proxy-ARP lookup for
IP1.
b. If the lookup is successful (as in Figure 1), PE3 will send an
ARP Reply with IP1->M1. The ARP Request will not be flooded to
the EVPN network or any other local CEs.
c. If the lookup is not successful, PE3 will flood the ARP Request
in the EVPN network and the other local CEs.
As PE3 learns more and more host entries in the Proxy-ARP/ND table,
the flooding of ARP Request messages is reduced and in some cases it
can even be suppressed. In a network where most of the participant
CEs are not moving between PEs and they advertise their presence with
GARPs or unsolicited NA messages, the ARP/ND flooding as well as the
unknown unicast flooding can practically be suppressed. In an EVPN-
based IXP network, where all the entries are Static, the ARP/ND
flooding is in fact totally suppressed.
The Proxy-ARP/ND function can be structured in six sub-functions or
procedures:
1. Learning sub-function
2. Reply sub-function
3. Unicast-forward sub-function
4. Maintenance sub-function
5. Flooding reduction/suppression sub-function
6. Duplicate IP detection sub-function
A Proxy-ARP/ND implementation MAY support all those sub-functions or
only a subset of them. The following sections describe each
individual sub-function.
3.1. High Level Design
3.1. Low Level Design