Yes, although I'm not sure if the same goal can be achieved with having multiple virtual-switches? Or they aren't supported? As the article says "This disparity can be confusing and lead to errors configuring EVPN across different platforms." So, mac-vrf also provides standardization between platforms, along with better scalability and tenant isolation.
Original Message:
Sent: 10-30-2023 11:05
From: aaron.gould
Subject: EVPN, MX, type-2 routes mac-ip issue
it sounds like mac-vrf takes the virtual-switch type even further... like mac-vrf can create several virtual-switches... ?
------------------------------
- Aaron
Original Message:
Sent: 10-30-2023 11:01
From: akostin
Subject: EVPN, MX, type-2 routes mac-ip issue
Hi Aaron,
From https://www.juniper.net/documentation/us/en/software/junos/evpn-vxlan/topics/concept/mac-vrf-routing-instance-overview.html :
"When you configure a MAC-VRF routing instance, you can isolate or group routing and forwarding traffic by customer. In fact, you can manage MAC-VRF instances around multiple schemes within an organization, including by department, division, or geographic location. The traffic belonging to any one MAC-VRF instance cannot interact with traffic from any other MAC-VRF instances."
Original Message:
Sent: 10-30-2023 10:19
From: aaron.gould
Subject: EVPN, MX, type-2 routes mac-ip issue
I use virtual-switch instance type. how does mac-vrf differ from evpn virtual-switch?
------------------------------
- Aaron
Original Message:
Sent: 10-30-2023 10:05
From: DMYTRO VASNIEV
Subject: EVPN, MX, type-2 routes mac-ip issue
arp-supression is one of reason i noticed EVPN. I have public IPs separated with super and sub vlans and have a lot of arp in these vlans.
I planned to use it with routing and l3-vni, not with bridging
And instance type evpn is not flexible, i use mac-vrf.
Thanks for answer
------------------------------
DMYTRO VASNIEV
Original Message:
Sent: 10-30-2023 09:52
From: akostin
Subject: EVPN, MX, type-2 routes mac-ip issue
In newer Junos versions no-arp-suppression is hidden:
[edit]
akostin@mpe01# set routing-instances TEST protocols evpn no-?
Possible completions:
no-control-word Disables control word on the Layer 2 encapsulation
no-mac-learning Disable dynamic MAC address learning
no-normalization Disable vlan id normalization for interfaces
[edit]
akostin@mpe01# set routing-instances TEST protocols evpn no-arp-suppression
[edit]
akostin@mpe01# show routing-instances TEST
protocols {
evpn {
##
## Warning: instance-type evpn must be configured
##
no-arp-suppression;
}
}
This is from ACX, may be different for MX though. In general, arp-suppression is a good thing, until it's absolutely necessary to disable it. I encountered a case when vlan translation is needed on ingress, vlan isn't translated for the first incoming ARP packet. Explanation from TAC: "since ARP suppression is enabled, ARP request reinjected by L2ALM will not perform VLAN translation. This can be overcome with configuring no-arp-suppression".
Original Message:
Sent: 10-28-2023 13:31
From: DMYTRO VASNIEV
Subject: EVPN, MX, type-2 routes mac-ip issue
Thank you for answer!
I thought mac-ip routes present in case when i configure l3vni to make routing instead of bridging. At least on other vendors(debian in particular) there are no mac-ip routes until you configure l3vni.
I dont have any irb interfaces in instance so its look confusive, a little bit.
I`ll try to turn off arp-supression and think about all of it.
------------------------------
DMYTRO VASNIEV
Original Message:
Sent: 10-28-2023 13:07
From: aaron.gould
Subject: EVPN, MX, type-2 routes mac-ip issue
I don't think you are doing anything wrong. In basic EVPN, you will see both of those Type 2 routes. One is for basic ethernet bridging, shown with only the mac address. The other one is for arp suppression, shown with the IP address also. ARP suppression is an efficiency mechanism built into EVPN. It allows a local EVPN edge router to respond on behalf of the remote device. In the link below, I read that ARP suppression can be disabled prior to Junos 19.1R1, but it seems that they've removed the ability to disable it from future releases. I looked for it in a lab vqfx running 20.3R1.8 and couldn't find it. I did find it in another lab vMX node running 18.2R1.9. I tried it and it worked. You probably want to make sure that is really the needed behavior before doing so.
https://www.juniper.net/documentation/us/en/software/junos/evpn-vxlan/topics/concept/evpn-proxy-arp-support.html
root@my-960> show route table my-evpn-01.evpn.0 evpn-mac-address 00:50:79:12:34:43 active-path
my-evpn-01.evpn.0: 16 destinations, 23 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2:10.10.128.9:5000::17::00:50:79:12:34:43/304 MAC/IP
*[EVPN/170] 00:00:07
Indirect
2:10.10.128.9:5000::17::00:50:79:12:34:43::172.16.17.9/304 MAC/IP
*[EVPN/170] 00:00:07
Indirect
root@my-960> show arp no-resolve interface irb.17
MAC Address Address Interface Flags
00:50:79:12:34:44 172.16.17.5 irb.17 [.local..11] permanent remote
00:50:79:12:34:43 172.16.17.9 irb.17 [ae141.17] permanent remote
Total entries: 2
root@my-960>
root@my-960> configure
Entering configuration mode
[edit]
root@my-960# set routing-instances my-evpn-01 bridge-domains bridge-0017 no-arp-suppression
[edit]
root@my-960# commit and-quit
commit complete
Exiting configuration mode
root@my-960> show route table my-evpn-01.evpn.0 evpn-mac-address 00:50:79:12:34:43 active-path
my-evpn-01.evpn.0: 15 destinations, 22 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2:10.10.128.9:5000::17::00:50:79:12:34:43/304 MAC/IP
*[EVPN/170] 00:00:08
Indirect
root@my-960>
root@my-960> show arp no-resolve interface irb.17
MAC Address Address Interface Flags
00:50:79:12:34:44 172.16.17.5 irb.17 [.local..11] permanent remote
root@my-960>
------------------------------
- Aaron
Original Message:
Sent: 10-27-2023 16:27
From: DMYTRO VASNIEV
Subject: EVPN, MX, type-2 routes mac-ip issue
Greetings!
I tying to build evpn-vxlan overlay and MX is a leaf/border-leaf in my fabric.
I trying to configure EVPN in mac-vrf and virtual-switch instance. Routes are advertising but there are mac and ip-mac type-2 routes, and i need only mac routes.
What im doing wrong?
My config is:
show mac-vrf
##
## inactive: routing-instances mac-vrf
##
instance-type mac-vrf;
protocols {
evpn {
encapsulation vxlan;
default-gateway do-not-advertise;
extended-vni-list [ 20601 20602 ];
multicast-mode ingress-replication;
vni-options {
vni 20601 {
vrf-target target:64601:20601;
}
vni 20602 {
vrf-target target:64601:20602;
}
}
}
}
vtep-source-interface lo0.0;
bridge-domains {
v601 {
domain-type bridge;
vlan-id 601;
vxlan {
vni 20601;
}
}
v602 {
domain-type bridge;
vlan-id 602;
vxlan {
vni 20602;
}
}
}
service-type vlan-aware;
interface et-0/0/0.601;
interface et-0/0/0.602;
route-distinguisher 64601:1;
vrf-target target:64514:10;
Interface:
show interfaces et-0/0/0.601
family bridge {
interface-mode trunk;
vlan-id-list 601;
}
and routes from this LEAF on SPINE:
2:64601:1::20602::30:b6:4f:55:90:a0/304 MAC/IP
*[BGP/170] 00:17:09, localpref 100, from 10.0.0.3
AS path: 64703 I, validation-state: unverified
> to 10.0.251.3 via irb.406
2:64601:1::20601::30:b6:4f:55:90:a0::10.133.61.3/304 MAC/IP
*[BGP/170] 00:03:50, localpref 100, from 10.0.0.3
AS path: 64703 I, validation-state: unverified
> to 10.0.251.3 via irb.406
#vxlan
#EVPN
------------------------------
DMYTRO VASNIEV
------------------------------