EVPN Multihoming
In an article on EVPN, I touched on the topic of multihoming. Many are interested in this topic and therefore in the continuation of the previous article today we will look at what is EVPN multihoming and how it works.
EVPN multihoming works in two modes: Single-Active and Active-Active. Today we mainly focus on a more complex and interesting variant: Active-Active, since Single-Active is essentially a very simplified version of Active-Active.
')
This article is intended for those who already have general knowledge about EVPN: the basic principles of work, differences from VPLS, etc. Otherwise, it will be difficult to understand the content of the article.
Note: I assembled the laboratory bench in EVE-NG using vMX: both the P-router and the switches are started by the vMX version 14.1, as by the PE routers of the vMX 16.1, as the final host of 5 Linux machines. Unlike the previous labs, which I collected on a laptop, this lab is too demanding on resources. The fact is that vMX 16.1 runs on two virtual machines and requires a total of 4 CPUs and 8GB of RAM. As a result, for the labs presented in the article, you need about 35GB of RAM on the server, but I want to note that in working condition the entire lab occupied slightly more than 23Gb of RAM (this must be borne in mind if you suddenly want to raise this lab at home).
We will consider this topology:
In the configuration I will use the vlan-aware method, that is, through a virtual switch, since this method is the most flexible and interesting, at least for me. Each PE router has three EVPN instances (abbreviated EVI - EVPN Instance), the configuration of which on all three PEs is about the same - the differences are only in RD, RT, and Vlan numbers. Two other instances have been added just to demonstrate some of the features of EVPN Multihoming clearly.
EVPN instances configuration looks like this:
bormoglotx@RZN-PE-1> show configuration routing-instances vSwitch-eVPN-1 instance-type virtual-switch; interface ae3.777; route-distinguisher 62.0.0.1:1; vrf-target target:42000:1; protocols { evpn { extended-vlan-list 777; } } bridge-domains { BRIDGE-777 { vlan-id 777; } } Nothing complicated: an instance with the type of virtual switch, RT, RD and just one bridge domain with vlan-id 777. The same vlan is listed in the extended list of evpn protocol vlans. For testing, we do not need anything else.
We now turn to the interface configuration. On RZN-PE-3, everything is simple and trite:
bormoglotx@RZN-PE-3> show configuration interfaces ae0 description "RZN-SW-3 | ae0"; flexible-vlan-tagging; encapsulation flexible-ethernet-services; aggregated-ether-options { lacp { active; periodic fast; } } unit 777 { description eVPN-1; encapsulation vlan-bridge; family bridge { interface-mode trunk; vlan-id-list 777; } } A simple unit that works as a trunk interface, in which only 777 vlan are allowed.
But on PE1 and PE2, the config is somewhat different from PE3, since the PE data is multihomed to RZN-SW-1:
bormoglotx@RZN-PE-1> show configuration interfaces ae3 description "RZN-SW-1 | ge-0/0/0 | ae3<<>>ae0 "; flexible-vlan-tagging; mtu 1600; encapsulation flexible-ethernet-services; esi { 00:00:00:00:00:00:00:00:00:01; all-active; } aggregated-ether-options { lacp { active; periodic fast; system-id 02:00:00:00:00:01; } } unit 777 { description eVPN-1; encapsulation vlan-bridge; family bridge { interface-mode trunk; vlan-id-list 777; } } Here we are interested in the appeared identifier ESI. Let me remind for those who have forgotten (or did not know) - this identifier must be assigned manually (when using MC-LAG it can be automatically generated), and all interfaces connected to the same segment should have the same identifier.
Note: for what purpose the system-id is specified here will be described at the end of the article
In our case, I chose a simple identifier 00: 00: 00: 00: 00: 00: 00: 00: 00: 01, since its value does not play a big role for us, the main thing is that it is different from the reserved values (all zeros and all units) and did not overlap with the value of already configured ESI values in other segments. That is, roughly speaking, ESI should be unique for the entire network where EVPN is running. For non-multihoming segments, this identifier does not play any role at all and is automatically set to 0-l. Naturally, even for non-multihoming PE routers, you can handle and set a non-zero ESI value on the links, and this will only entail the generation of extra routes - that is, in fact, there will be no problems as such. But if this ESI value given by the handles coincides with the value of the ESI already configured on another or other junctions, then you will start having problems.
There are 5 types of routes in EVPN (I did not consider type 5 last time, but I will try to touch on this topic in an article on EVPN / VxLAN):
Type 2 is the MAC / IP route. This route tells the PE router where and with what label to send unicast packets to the specific MAC address specified in the route. Essentially analogous to the announcement of the vpnv4 prefix in L3VPN. The route may also contain the ip address of the host.
Type 3 is the Inclusive Multicast route. This route tells the PE router where and with what label to send BUM traffic.
Type 1 and 4 are the main routes that provide us with EVPN Multihoming functionality. We will consider them further.
So, at the 0th time point, as soon as we started EVPN, routers start sending each other type 3 routes, so that we can exchange BUM traffic. This is true for a non-multihoming script. Since in our segment two routers look into the same segment, then we have routes like 1 and 4. Why do we need route 3 you should already know, so then we will focus on routes 1 and 4.
As I wrote above, we just launched EVPN and so far there was no traffic exchange between the hosts, as indicated by the lack of MAC addresses in the forwarding table of the vSwitch-eVPN-1 instance:
bormoglotx@RZN-PE-1> show evpn instance vSwitch-eVPN-1 brief Intfs IRB intfs MH MAC addresses Instance Total Up Total Up Nbrs ESIs Local Remote vSwitch-eVPN-1 1 1 0 0 2 1 0 0 In the presented output, it is clear that we have a multihomed segment. To find out information about this segment, we will review the extensive output of the previous command:
bormoglotx@RZN-PE-1> show evpn instance vSwitch-eVPN-1 extensive Instance: vSwitch-eVPN-1 Route Distinguisher: 62.0.0.1:1 Per-instance MAC route label: 299792 Per-instance multicast route label: 299776 MAC database status Local Remote MAC advertisements: 0 0 MAC+IP advertisements: 0 0 Default gateway MAC advertisements: 0 0 Number of local interfaces: 1 (1 up) Interface name ESI Mode Status ae3.777 00:00:00:00:00:00:00:00:00:01 all-active Up Number of IRB interfaces: 0 (0 up) Number of bridge domains: 1 VLAN Domain ID Intfs / up IRB intf Mode MAC sync IM route label 777 1 1 Extended Enabled 299776 Number of neighbors: 2 62.0.0.2 Received routes MAC address advertisement: 0 MAC+IP address advertisement: 0 Inclusive multicast: 1 Ethernet auto-discovery: 2 62.0.0.3 Received routes MAC address advertisement: 0 MAC+IP address advertisement: 0 Inclusive multicast: 1 Ethernet auto-discovery: 0 Number of ethernet segments: 1 ESI: 00:00:00:00:00:00:00:00:00:01 Status: Resolved by IFL ae3.777 Local interface: ae3.777, Status: Up/Forwarding Number of remote PEs connected: 1 Remote PE MAC label Aliasing label Mode 62.0.0.2 300208 300208 all-active Designated forwarder: 62.0.0.2 Backup forwarder: 62.0.0.1 Last designated forwarder update: May 07 06:59:19 Advertised MAC label: 300112 Advertised aliasing label: 300112 Advertised split horizon label: 302752 This output gives us full information on our EVPN instance. Some of the fields should be clear to you. According to this conclusion, we have ESI 00: 00: 00: 00: 00: 00: 00: 00: 00: 01, which works in Active-Active mode:
Number of local interfaces: 1 (1 up) Interface name ESI Mode Status ae3.777 00:00:00:00:00:00:00:00:00:01 all-active Up The output below provides information on each PE router participating in this EVPN domain:
Number of neighbors: 2 62.0.0.2 Received routes MAC address advertisement: 0 MAC+IP address advertisement: 0 Inclusive multicast: 1 Ethernet auto-discovery: 2 Judging by the information above from RZN-PE-2, we get one type 3 route and two type 1 routes. The truth is not quite so. In addition to these routes, RZN-PE-2 gives us another type 4 route, but why it is not shown here, we will see later.
But from RZN-PE-3 at the moment we get only one type 3 route and that’s all:
62.0.0.3 Received routes MAC address advertisement: 0 MAC+IP address advertisement: 0 Inclusive multicast: 1 Ethernet auto-discovery: 0 This is logical, since this PE router is not multihomed and so far all we need to know from it is type 3 route. Further as you study poppies, this router will start sending type 2 announcements, but so far it has not learned any poppies. If we had configured default gateways, we would have type 2 routes (depending on the number of irb interfaces added to the instance).
In addition to the information described above for our EVI, the output indicates that for the segment with ESI 00: 00: 00: 00: 00: 00: 00: 00: 00: 01, Designated forwarder is selected and the Aliasing label is indicated:
Number of ethernet segments: 1 ESI: 00:00:00:00:00:00:00:00:00:01 Status: Resolved by IFL ae3.777 Local interface: ae3.777, Status: Up/Forwarding Number of remote PEs connected: 1 Remote PE MAC label Aliasing label Mode 62.0.0.2 300208 300208 all-active Designated forwarder: 62.0.0.2 Backup forwarder: 62.0.0.1 At the moment, many of the findings are not clear. To understand the principles of EVPN Multihoming, we need to understand at least the following questions:
1. Why does the Multihomed PE router begin to announce additional routes of type 1 and 4, what is their purpose;
2. What is DF and how are its choices made;
3. Why are there two type 1 routes?
4. What is the Aliasing label in the output above.
But these and some other questions I will try to answer further.
Multihoming-ha problems.
To begin, let us indicate what problems we have if we turn on Multihoming in Active-Active mode. Naturally, the most acute problem will be loops (well, or cycles, as you like), since EVPN is still L2VPN. In fact, if you overcome this problem, the technology will already be better than the same VPLS, which in All-Active mode does not know how to work at all. Another important problem will be traffic balancing, since not all multihomed PE routers will learn Macs from the client. Other problems are less critical, let's say more precisely - although there are other problems, but their presence does not make the technology unviable.
Let's look at how these problems are solved in EVPN.
Fighting loops has a whole range of measures. The first naturally split horizon - a frame received from other PE routers (that is, from the kernel) is not sent again to the kernel. But of course this is not enough, since the main place of the network where a loop may occur is connecting the multihomed CE of the switch to several PE routers. To eliminate loops in this segment, Designated Forwarder and Split Horizon Label are used, But first things first.
What is DF and why is it needed?
The first scenario of a loop: imagine that a remote PE router receives BUM traffic from CE (for example, a banal arp request) and sends it to all other PEs (suppose it is PE3). Since the two PE routers (PE1 and PE2) look in the same segment and they both receive BUM traffic from PE3, it turns out that two copies of traffic will fly to this segment, which will then start to wind across all networks, including the core:
To combat this phenomenon, a Designated Forwarder is chosen for each multihomed segment in EVPN - the node responsible for forwarding BUM traffic towards a specific segment in a particular plane. All other routers, no matter how many of them are in the segment, I have no right to send BUM traffic towards the CE of the router / switch (in this ESI in this vlan).
DF Selection Algorithm:
1. First, all PE routers must understand how many more routers are connected to the specified segment and what addresses they have (lupbacks);
2. After the timer expires (3 seconds by default), a list of all PE routers participating in the DF selection is formed, starting with the smallest address and ending with the largest one. The address list is numbered from 0 to;
3. According to the formula V mod N = i, DF is calculated for this segment and vlan;
4. The router selected by the DF will unblock BUM traffic towards CE, and all other non-DF routers continue to block BUM traffic towards the CE of a router / switch in this segment in the given plane.
In theory, everything is simple, but let's order.
First, we will answer the question of how routers understand who else has a link in the same segment (and are there any such routers at all)? For this, there is a route of type 4. Look at this route:
bormoglotx@RZN-PE-1> show route table vSwitch-eVPN-1.evpn.0 match-prefix *4:6* vSwitch-eVPN-1.evpn.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) In the routing table of our EVPN instance there are no such routes. The fact is that only those routes fall into this table, the extended community of which corresponds to the import configured in the instance. For example, for vSwitch-eVPN-1 is:
bormoglotx@RZN-PE-1> show configuration routing-instances vSwitch-eVPN-1 vrf-target target:42000:1; It turns out that the type 4 route has some other route than the one configured for the import community. This is due to the fact that the routes in evpn can be generated in two ways - per-EVI and per-ESI.
per-EVI - this route is generated by a specific instance
per-ESI - this route is not generated by any specific instance, but by the router for all insatns who have a link in this ESI. The same segment can be included in several evpn instances (for example, the ae3.777 interface has been added to the EVPN1 instance, and the ae3.778 interface has been added to EVPN2, although these are different units, the ESI is configured for the entire interface, which means for the data interfaces will be the same ESI, although they are in different EVI).
Routes generated by per-EVI should have native RT and RD instances, from which these routes are announced (or some other RT, if they are additionally attached by export policy - that is, they are added manually by administrators). Type 2 and 3 routes are always generated by per-EVI, which means that they always have a native RD and RT instance as part of the route, from which these routes are announced. But for the routes generated by per-ESI, everything is somewhat more complicated and depends on the type of route.
But let's continue to deal with the type 4 route.
This route is always generated by per-esi. The RD of this route will be generated automatically by the router from the router-id (if specified) or the loopback address (since this route is not related to any of the EVPN instances). RT is also not specified manually, but is generated from ESI and only those routers that have the same ESI import this route. That is why in the conclusion, considered earlier at the beginning of the article, we do not see that the multihomed neighbor announces a type 4 route to us.
Note: it’s not quite true at all, since only part of the ESI bits are taken for RT and all PEs that have the same ESI bits used to generate the RT will import this route.
Note: JunOS generates RD for per-ESI routes using a zero value in the second part of RD: 62.0.0.1: 0 .
So where to look for our type 4 route? JunOS has several routing tables. EVPN routes first enter the bgp.evpn.0 table and are already imported from it into some other routing tables (secondary tables). Therefore, this route can be found in the bgp.evpn.0 table, from which it is exported to the __ default_evpn __. Evpn.0 table:
bormoglotx@RZN-PE-1> show route table __default_evpn__.evpn.0 match-prefix *4:6* __default_evpn__.evpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 4:62.0.0.1:0::01:62.0.0.1/304 ES *[EVPN/170] 02:57:15 Indirect 4:62.0.0.2:0::01:62.0.0.2/304 ES *[BGP/170] 02:57:16, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.0.1 via ae0.1 As I said, the RD is automatically generated by the router: 62.0.0.1 in the route from RZN-PE-1 (next-hop indirect, since the route is local to this router) and 62.0.0.2 in the route from RZN-PE- 2 There is no route from RZN-PE-3, as this PE router is not multihomed. Moreover, since there is no such ESI on PE-3, these routes are not imported by this router, although the reflector faithfully gives them to it:
bormoglotx@RZN-PE-3> show route table __default_evpn__.evpn.0 bormoglotx@RZN-PE-3> bormoglotx@RZN-P-1> show route advertising-protocol bgp 62.0.0.3 | match 4:62 4:62.0.0.1:0::01:62.0.0.1/304 4:62.0.0.2:0::01:62.0.0.2/304 Now we will analyze this route in more detail:
bormoglotx@RZN-PE-1> show route table __default_evpn__.evpn.0 match-prefix *4:6* next-hop 62.0.0.2 detail __default_evpn__.evpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) 4:62.0.0.2:0::01:62.0.0.2/304 ES (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 62.0.0.2:0 Next hop type: Indirect, Next hop index: 0 Address: 0xb1e55f0 Next-hop reference count: 20 Source: 62.0.0.100 Protocol next hop: 62.0.0.2 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 State: <Secondary Active Int Ext> Local AS: 42000.62 Peer AS: 42000.62 Age: 2:58:04 Metric2: 1 Validation State: unverified Task: BGP_42000.62.62.0.0.100 Announcement bits (1): 0-__default_evpn__-evpn AS path: I (Originator) Cluster list: 62.0.0.100 Originator ID: 62.0.0.2 Communities: es-import-target:0-0-0-0-0-0 Import Accepted Localpref: 100 Router ID: 62.0.0.100 Primary Routing Table bgp.evpn.0 Especially nothing criminal - most of the fields are peculiar to the BGP route. But here in the community line we are usually used to seeing for example the domain-id, origin or target community. Immediately completely different community.
This is specifically reserved for the EVPN community. As I wrote above, this route is generated exclusively by per-ESI and only those PE routers that need this route should receive it. And it is needed only for those PEs who have a link in the same ESI as the sender of the route. Therefore, the community of this route is generated based on ESI and has the form es-import-target: 0-0-0-0-0-0.
In our case, all zeros, and I specifically took such an ESI to show that this community can contain only zeros in its second part (the first part is reserved and equal to 0x06 (type) and 0x02 (sub type), who are interested in reading the RFC ) and This does not affect the performance of EVPN. As a result, in our laboratory network only RZN-PE-1 and RZN-PE-2 import this route.
And where is ESI, you ask? The identifier is directly in the route itself: 4: 62.0.0.2: 0 :: 01 : 62.0.0.2/304 ES, just empty octets (zeros) are omitted (like ipv6). And it’s not hard to guess if two routers will have links in different segments, but their identifiers will be 00: 00: 00: 00: 00: 00: 00: 00: 01 for the first and 10 : 00: 00: 00 : 00: 00: 00: 00: 00: 01 from the second one, then the routes will be imported by both routers. According to the community, only the initial filtering occurs - the route itself will be used only if the ESI specified in the route matches the ESI on the router itself, which this route received, otherwise the route will be discarded.
As soon as the router understands that it is multihomed (it understands this by the non-zero value of ESI in the interface configuration), it begins to send a type 4 route so that all neighboring routers are aware of its presence on the network.
After the routes have spread over the network, the RZN-PE-1 and RZN-PE-2 will know that they are connected to the same ESI. Both routers wait for 3 seconds (by default) type 4 routes from other PE routers, after which, based on the type 4 routes received from neighbors, they make a list of all nodes connected to this segment, and on all nodes this list will be the same our case is this:
62.0.0.1 i = 0
62.0.0.2 i = 1
After that, the routers begin to calculate who DF will be according to the formula V mod N = i, where V is the number of the vlan, and N is the number of PE routers in the segment. The PE router whose number will be the result of the calculation and becomes the DF of this segment in the given plane. As you understand, each VF will have its own DF - it turns out some balancing of BUM traffic.
There are three EVPN instances configured in the laboratory, one instance corresponds to each instance, I used 777, 778 and 779 Vlans. Since we have 2 multihomed PE-ek, the number of nodes is 2. We get that in this segment DF-ohm for Vlan 777 and 779 will be chosen RZN-PE-2, and for 778 - RZN-PE-1, which is easy to check:
bormoglotx@RZN-PE-1> show configuration routing-instances | display set | match interface set routing-instances vSwitch-eVPN-1 interface ae3.777 set routing-instances vSwitch-eVPN-2 interface ae3.778 set routing-instances vSwitch-eVPN-3 interface ae3.779 bormoglotx@RZN-PE-1> show configuration interfaces ae3 | display set | match vlan-id set interfaces ae3 unit 777 family bridge vlan-id-list 777 set interfaces ae3 unit 778 family bridge vlan-id-list 778 set interfaces ae3 unit 779 family bridge vlan-id-list 779 bormoglotx@RZN-PE-1> show evpn instance vSwitch-eVPN-1 designated-forwarder Instance: vSwitch-eVPN-1 Number of ethernet segments: 1 ESI: 00:00:00:00:00:00:00:00:00:01 Designated forwarder: 62.0.0.2 bormoglotx@RZN-PE-1> show evpn instance vSwitch-eVPN-2 designated-forwarder Instance: vSwitch-eVPN-2 Number of ethernet segments: 1 ESI: 00:00:00:00:00:00:00:00:00:01 Designated forwarder: 62.0.0.1 bormoglotx@RZN-PE-1> show evpn instance vSwitch-eVPN-3 designated-forwarder Instance: vSwitch-eVPN-3 Number of ethernet segments: 1 ESI: 00:00:00:00:00:00:00:00:00:01 Designated forwarder: 62.0.0.2 This scheme has its pros and cons. The most obvious disadvantage is the DF selection mechanism itself. As soon as a new router appears in the segment that has a link in the direction of ESI X or a link drops / restores on the router in the direction of ESI X, the DF is recalculated for this segment. And the worst situation will be the disappearance of the link in the direction of ESI X on the DF router. Since the rest of the routers block BUM traffic transmission to the device CE side, for the time of detecting the fall of the DF and calculating the new DF, the BUM traffic will be dropped by all the PE routers of the segment, since at this point in time they will all be non-DF. But now there is a draft RFC that describes the new DF selection procedure. But so far everything works as described.
It is worth mentioning that the choice of DF for vlan-aware and vlan-bundle methods is slightly different. -, DF , , . 30,778 779. , — 30, DF- PE1 — 62.0.0.1:
bormoglotx@RZN-PE-1> show evpn instance vSwitch-eVPN-1 extensive | match "domain|extended|forwarder" Number of bridge domains: 4 VLAN Domain ID Intfs / up IRB intf Mode MAC sync IM route label 30 1 1 Extended Enabled 300384 777 1 1 irb.1 Extended Enabled 300384 778 1 1 Extended Enabled 300384 779 1 1 Extended Enabled 300384 Designated forwarder: 62.0.0.1 Backup forwarder: 62.0.0.2 Last designated forwarder update: May 24 08:12:13 30- . 777, DF- PE2 — 62.0.0.2:
bormoglotx@RZN-PE-1> show evpn instance vSwitch-eVPN-1 extensive | match "domain|extended|forwarder" Number of bridge domains: 4 VLAN Domain ID Intfs / up IRB intf Mode MAC sync IM route label 777 1 1 irb.1 Extended Enabled 300384 778 1 1 Extended Enabled 300384 779 1 1 Extended Enabled 300384 Designated forwarder: 62.0.0.2 Backup forwarder: 62.0.0.1 Last designated forwarder update: May 24 08:14:52 : , Backup forwarder Backup Designated forwarder (BDF). BDF non-DF . EVPN ( OSPF DR BDR) — DF , non-DF BDF. DF.
4 .
DF . CE non-DF . , RZN-PE-1, non-DF BUM RZN-SW-1 , : RZN-PE-1, BUM CE, PE-, RZN-PE-2. RZN-PE-2, DF , RZN-SW-1, . :
-.
1, per-ESI.
4, 1, per-ESI, per-EVI community , ( , ):
bormoglotx@RZN-PE-1> show route table vSwitch-eVPN-1.evpn.0 match-prefix *1:6* vSwitch-eVPN-1.evpn.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1:62.0.0.1:1::01::0/304 AD/EVI *[EVPN/170] 1d 00:09:01 Indirect 1:62.0.0.2:0::01::FFFF:FFFF/304 AD/ESI *[BGP/170] 03:20:10, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.0.1 via ae0.1 1:62.0.0.2:1::01::0/304 AD/EVI *[BGP/170] 1d 00:09:01, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.0.1 via ae0.1 1 per-ESI?
1 .
per-ESI 1 community mpls , split horizon label:
bormoglotx@RZN-PE-1> show route table vSwitch-eVPN-1.evpn.0 match-prefix *FFFF* detail vSwitch-eVPN-1.evpn.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) 1:62.0.0.2:0::01::FFFF:FFFF/304 AD/ESI (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 62.0.0.2:0 Next hop type: Indirect, Next hop index: 0 Address: 0xb1e55f0 Next-hop reference count: 20 Source: 62.0.0.100 Protocol next hop: 62.0.0.2 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 State: <Secondary Active Int Ext> Local AS: 42000.62 Peer AS: 42000.62 Age: 3:20:48 Metric2: 1 Validation State: unverified Task: BGP_42000.62.62.0.0.100 Announcement bits (1): 0-vSwitch-eVPN-1-evpn AS path: I (Originator) Cluster list: 62.0.0.100 Originator ID: 62.0.0.2 Communities: target:42000:1 target:42000:2 target:42000:3 esi-label:all-active (label 302656) Import Accepted Localpref: 100 Router ID: 62.0.0.100 Primary Routing Table bgp.evpn.0 :
Communities: target:42000:1 target:42000:2 target:42000:3 esi-label:all-active (label 302656) ? , non-DF , BUM DF-, , community. : PE BUM ESI X, non-DF . PE- EVPN , PE-, ESI X. PE- — IM , , DF- ESI X, Split horizon IM . DF , ESI X . , , DF , non-DF ESI X.
DF :
IM S=1 ( — ), CE-/ EVPN .
IM S=0 ( — ), mpls lookup. lookup Split Horizon S=1. CE /, , , .
, per-ESI, 4 community ( )? , split horizon label. community esi-label: all-active (label 302656), , all-active single-active. PE-, — PE- ( ) Aliasing label.
— . CE , , . , PE- , withdraw , MAC/IP , ESI, . ? withdraw 1, PE , PE . MAC Mass Withdraw. , , MAC- .
, (-) community — PE3 ESI 00:00:00:00:00:00:00:00:00:01 community , 4, PE-3 , community.
: 1, per-ESI, : 1:62.0.0.2:0::01:: FFFF:FFFF /304 AD/ESI. Juniper, RFC — 1, per-ESI tag-id ( 32-), mpls 0.
EVPN . , 2 1. ? , 1 per-EVI.
1, per-EVI?
bormoglotx@RZN-PE-1> show route table vSwitch-eVPN-1.evpn.0 match-prefix *01::0* vSwitch-eVPN-1.evpn.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1:62.0.0.1:1::01::0/304 AD/EVI *[EVPN/170] 1d 00:20:59 Indirect 1:62.0.0.2:1::01::0/304 AD/EVI *[BGP/170] 1d 00:20:59, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.0.1 via ae0.1 aliasing label:
bormoglotx@RZN-PE-1> show route table vSwitch-eVPN-1.evpn.0 match-prefix *01::0* detail next-hop 62.0.0.2 vSwitch-eVPN-1.evpn.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) 1:62.0.0.2:1::01::0/304 AD/EVI (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 62.0.0.2:1 Next hop type: Indirect, Next hop index: 0 Address: 0xb1e55f0 Next-hop reference count: 20 Source: 62.0.0.100 Protocol next hop: 62.0.0.2 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 State: <Secondary Active Int Ext> Local AS: 42000.62 Peer AS: 42000.62 Age: 1d 0:20:26 Metric2: 1 Validation State: unverified Task: BGP_42000.62.62.0.0.100 Announcement bits (1): 0-vSwitch-eVPN-1-evpn AS path: I (Originator) Cluster list: 62.0.0.100 Originator ID: 62.0.0.2 Communities: target:42000:1 Import Accepted Route Label: 300208 Localpref: 100 Router ID: 62.0.0.100 Primary Routing Table bgp.evpn.0 Route Label: 300208 — aliasing , , 2 . , 2? , EVPN L2VPN — , . , PE- MAC- data plane. , multihomed CE PE- ( — ). MAC CE / MAC/IP:
, , MAC- RZN-PE-2 ( DF 777 ), data plane ( ):
bormoglotx@RZN-PE-2> show bridge mac-table MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) Routing instance : vSwitch-eVPN-1 Bridging domain : BRIDGE-777, VLAN : 777 MAC MAC Logical NH RTR addresssss flags interface Index ID 00:05:86:71:87:c0 DC 1048585 1048585 00:05:86:71:87:f0 D ae3.777 00:50:79:66:68:0c D ae3.777 <<<<<<<<<<<<<< 00:50:79:66:68:0d D ae3.777 <<<<<<<<<<<<<< 00:50:79:66:68:0e D ae3.777 MAC- RZN-PE-1 data plane:
bormoglotx@RZN-PE-1> show bridge mac-table MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) Routing instance : vSwitch-eVPN-1 Bridging domain : BRIDGE-777, VLAN : 777 MAC MAC Logical NH RTR addresssss flags interface Index ID 00:05:86:71:87:c0 DC 1048586 1048586 00:05:86:71:87:f0 D ae3.777 00:50:79:66:68:0c DRC ae3.777 <<<<<<<<<<<<<< 00:50:79:66:68:0d DRC ae3.777 <<<<<<<<<<<<<< 00:50:79:66:68:0e D ae3.777 ? , RZN-PE-2 MAC RZN-SW-1 MAC/IP , ( ). RZN-PE-3, , control plane:
bormoglotx@RZN-PE-3> show bridge mac-table MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) Routing instance : vSwitch-eVPN-1 Bridging domain : BRIDGE-777, VLAN : 777 MAC MAC Logical NH RTR addresssss flags interface Index ID 00:05:86:71:87:c0 D ae0.777 00:05:86:71:87:f0 DC 1048580 1048580 00:50:79:66:68:0c DC 1048580 1048580 <<<<<<<<<<<<<< 00:50:79:66:68:0d DC 1048580 1048580 <<<<<<<<<<<<<< 00:50:79:66:68:0e DC 1048580 1048580 RZN-PE-3, , RZN-PE-1 RZN-PE-2 . , RZN-PE-1:
bormoglotx@RZN-PE-3> show route table vSwitch-eVPN-1.evpn.0 match-prefix *2:6* next-hop 62.0.0.1 vSwitch-eVPN-1.evpn.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 2:62.0.0.1:1::777::00:05:86:71:87:f0/304 MAC/IP *[BGP/170] 00:07:34, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.3.0 via ae3.0, Push 299824 2:62.0.0.1:1::777::00:50:79:66:68:0e/304 MAC/IP *[BGP/170] 00:01:25, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.3.0 via ae3.0, Push 299824 , RZN-PE-2:
bormoglotx@RZN-PE-3> show route table vSwitch-eVPN-1.evpn.0 match-prefix *2:6* next-hop 62.0.0.2 vSwitch-eVPN-1.evpn.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 2:62.0.0.2:1::777::00:05:86:71:87:f0/304 MAC/IP *[BGP/170] 00:07:36, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.3.0 via ae3.0, Push 299840 2:62.0.0.2:1::777::00:50:79:66:68:0c/304 MAC/IP <<<<<<<<<<<<<< *[BGP/170] 00:01:32, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.3.0 via ae3.0, Push 299840 2:62.0.0.2:1::777::00:50:79:66:68:0d/304 MAC/IP <<<<<<<<<<<<<< *[BGP/170] 00:01:36, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.3.0 via ae3.0, Push 299840 2:62.0.0.2:1::777::00:50:79:66:68:0e/304 MAC/IP *[BGP/170] 00:01:27, localpref 100, from 62.0.0.100 AS path: I, validation-state: unverified > to 10.0.3.0 via ae3.0, Push 299840 , RZN-PE-2. RZN-PE-3 , RZN-PE-1 RZN-PE-2 MAC. , RZN-PE-1 RZN-PE-2. , EVPN . 2 (MAC/IP) ESI, MAC-. RZN-PE-1, 2, , MAC , . RZN-PE-1 next-hop- RZN-PE-2, ESI:
bormoglotx@RZN-PE-1> show bridge mac-table MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) Routing instance : vSwitch-eVPN-1 Bridging domain : BRIDGE-777, VLAN : 777 MAC MAC Logical NH RTR addresssss flags interface Index ID 00:05:86:71:87:c0 DC 1048586 1048586 00:05:86:71:87:f0 D ae3.777 00:50:79:66:68:0c DRC ae3.777 <<<<<<<<<<<<<< 00:50:79:66:68:0d DRC ae3.777 <<<<<<<<<<<<<< 00:50:79:66:68:0e D ae3.777 , MAC ae3.777, , , control plane PE-. , RZN-PE-1 MAC data plane, RZN-SW-1 .
— RZN-PE-3 MAC RZN-PE-2, RZN-PE-1 MAC/IP MAC , RZN-PE-3 RZN-PE-1? aliasing label.
RZN-PE-3 ( 1, per-ESI), RZN-PE-1 RZN-PE-2 Active-Active. , RZN-PE-3 aliasing label, . RZN-PE-3 , RZN- SW-1 RZN-PE-2, , 2, RZN-PE-1, aliasing label , 1.
Aliacing label multihomed , RZN-PE-3:
bormoglotx@RZN-PE-3> show evpn instance vSwitch-eVPN-1 extensive | find "ESI: " ESI: 00:00:00:00:00:00:00:00:00:01 Status: Resolved by NH 1048580 Number of remote PEs connected: 2 Remote PE MAC label Aliasing label Mode 62.0.0.1 300112 300112 all-active 62.0.0.2 300208 300208 all-active bormoglotx@RZN-PE-3> show evpn instance vSwitch-eVPN-2 extensive | find "ESI: " ESI: 00:00:00:00:00:00:00:00:00:01 Status: Resolved by NH 1048583 Number of remote PEs connected: 2 Remote PE MAC label Aliasing label Mode 62.0.0.1 0 302240 all-active 62.0.0.2 0 302272 all-active bormoglotx@RZN-PE-3> show evpn instance vSwitch-eVPN-3 extensive | find "ESI: " ESI: 00:00:00:00:00:00:00:00:00:01 Status: Resolved by NH 1048588 Number of remote PEs connected: 2 Remote PE MAC label Aliasing label Mode 62.0.0.2 0 302624 all-active 62.0.0.1 0 302560 all-active mpls.0 Ingress-Aliasing:
bormoglotx@RZN-PE-1> show route table mpls.0 label 302560 mpls.0: 32 destinations, 33 routes (32 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 302560 *[EVPN/7] 03:49:28, routing-instance vSwitch-eVPN-3, route-type Ingress-Aliasing to table vSwitch-eVPN-3.evpn-mac.0 , Juniper MAC/IP per-EVI ( ). , aliasing label mac-label. :
bormoglotx@RZN-PE-3> show evpn instance vSwitch-eVPN-1 extensive | find "ESI: " ESI: 00:00:00:00:00:00:00:00:00:01 Status: Resolved by NH 1048580 Number of remote PEs connected: 2 Remote PE MAC label Aliasing label Mode 62.0.0.1 300112 300112 all-active 62.0.0.2 300208 300208 all-active , MAC label = Aliasing label. , JunOS MAC per-EVI :
bormoglotx@RZN-PE-3> show route table vSwitch-eVPN-1.evpn.0 next-hop 62.0.0.1 match-prefix *2:6* detail | match label Route Label: 300112 Route Label: 300112 Route Label: 300112 Route Label: 300112 RZN-PE-1 2, . , aliasing label, mac label? , Juniper, — Cisco, Brocade, Huawei ALu — .
, aliasing ? . RZN-PE-3 1 per-EVI RZN-PE-1 RZN-PE-2, aliasing . 1 per-ESI RZN-PE-3 . , RZN-PE-3 aliasing , , multihomed Single-Active , , . RZN-PE-3 , . How to be? RFC — 1, per-ESI multihoming-, aliasing , 1 per-EVI.
Single-Active . multihomed PE-, , .
MC-LAG EVPN?
multihomed CE PE- LAG. PE- , , CE- LAG, PE-, MC-LAG, CE / , . :
RZN-SW-1 LAG :
bormoglotx@RZN-SW-1> show configuration interfaces ae0 description "LAG to RZN-PE-1/2 | ae0<<>>ae3"; flexible-vlan-tagging; mtu 1600; encapsulation flexible-ethernet-services; aggregated-ether-options { lacp { active; periodic fast; PE-:
bormoglotx@RZN-SW-1> show configuration interfaces ge-0/0/0 description "RZN-PE-1 | ae1<<>>ae3"; gigether-options { 802.3ad ae0; } bormoglotx@RZN-SW-1> show configuration interfaces ge-0/0/1 description "RZN-PE-2 | ae2<<>>ae3"; gigether-options { 802.3ad ae0; } PE- MC-LAG, EVPN/MPLS . PE- LAG CE system-id, MAC PE- CE ( CE MAC-):
bormoglotx@RZN-PE-1> show configuration interfaces ae3 description "RZN-SW-1 | ge-0/0/0 | ae3<<>>ae0 "; flexible-vlan-tagging; mtu 1600; encapsulation flexible-ethernet-services; esi { 00:00:00:00:00:00:00:00:00:01; all-active; } aggregated-ether-options { lacp { active; periodic fast; system-id 02:00:00:00:00:01; bormoglotx@RZN-PE-2> show configuration interfaces ae3 description "RZN-SW-1 | ae3<<>>ae0 | MC-LAG with RZN-PE-2"; flexible-vlan-tagging; mtu 1600; encapsulation flexible-ethernet-services; esi { 00:00:00:00:00:00:00:00:00:01; all-active; } aggregated-ether-options { lacp { active; periodic fast; system-id 02:00:00:00:00:01; , .
RZN-SW-1:
bormoglotx@RZN-SW-1> show lacp interfaces ae0 Aggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity ge-0/0/0 Actor No No Yes Yes Yes Yes Fast Active ge-0/0/0 Partner No No Yes Yes Yes Yes Fast Active ge-0/0/1 Actor No No Yes Yes Yes Yes Fast Active ge-0/0/1 Partner No No Yes Yes Yes Yes Fast Active LACP protocol: Receive State Transmit State Mux State ge-0/0/0 Current Fast periodic Collecting distributing ge-0/0/1 Current Fast periodic Collecting distributing PE :
bormoglotx@RZN-PE-1> show lacp interfaces ae3 Aggregated interface: ae3 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity ge-0/0/4 Actor No No Yes Yes Yes Yes Fast Active ge-0/0/4 Partner No No Yes Yes Yes Yes Fast Active LACP protocol: Receive State Transmit State Mux State ge-0/0/4 Current Fast periodic Collecting distributing bormoglotx@RZN-PE-2> show lacp interfaces ae3 Aggregated interface: ae3 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity ge-0/0/4 Actor No No Yes Yes Yes Yes Fast Active ge-0/0/4 Partner No No Yes Yes Yes Yes Fast Active LACP protocol: Receive State Transmit State Mux State ge-0/0/4 Current Fast periodic Collecting distributing , PE- , CE — LAG ( LACP).
— MC-LAG (ICCP, ICL). , . EVPN/MPLS MC-LAG , , MC-LAG All-Active ICL, , MC-LAG ( ).
EVPN MC-LAG , EVPN ( VPLS L2CKT — EVPN). , MC-LAG 2- (EVPN multihoming 2- PE- Active-Active); PE-, ( MC-LAG) .
, EVPN multihoming, VPLS. EVPN Active-Active multihoming . 100Mbps 50Mbos, , , , . L2VPN multihoming Active-Active?
, , .
Thanks for attention.
Source: https://habr.com/ru/post/329100/
All Articles