the term routing instance in JUNOS might be a little confusing, but EVPN is actually a Layer-2 VPN service, i.e. the EVPN handles Ethernet frames. The Layer-3 IP functionality is done by the IRB (integrated route bridging) interface.
yes and now. The irb-interface is a logical interface which has one leg in a layer-2 domain and one leg in a layer-3 domain. The layer-3 part of it resides either in the inet.0 (by default) or any other VRF or virtual router, while the layer-2 part is attached to the EVPN.
Talking about VMTO, what's the advantage of EVPN versus VPLS/Bridge Domains? Let's consider you have two MX-series R1 and R2 configured with a standard bridge domain or VPLS and R2 has an irb interface configured to provide the default gateway for your layer-2 network. If a frame arrives on R1 for the default gateway, the frames has to be forwarded inside the bridge domain to R2 and the layer-3 processing will be done on R2, i.e. forwarding the packet to whatever destination. In case the destination IP network is connected to R1, the packet get's sent back on R2 with a routing instance (or inet.0).
With EVPN, R2 would not only sent the MAC address of the default gateway (which is his own irb) but also the IP address binding (similar to an ARP entry) which allows R1 to process the packet locally, e.g. answer ARP requests for the default gateway, forward the packet if the routing instance is locally available, etc.
EVPN allows for the integration of Layer 3 routing to the Layer 2 domain via configuration of an IRB interface for the VLAN in the EVPN instance. The IRB interface is then placed in an IP VPN on the PE. Hosts in the EVPN use the IRB interface as their default gateway, which can route to destinations external to the data center or to other data center subnets using the IP VPN’s VRF.
so the simple act of setting the command:
does not place the irb L3 interface into the evpn instance. it keeps it inside inet.0 unless you make a seperate L3VPN and add the irb interface into it?
I was under the impression that it was more of an integrated L2/L3 routing-instance. It would seem you need an evpn instance for the L2 and possibly an L3VPN instance for L3 routing side, depending on seperation requirements?
//Note just re-read your post and you already answered this! needed time for brain to catchup!!!
As they are seperate routing-instance they will need seperate RD and VRF-target tags?
Hi wjonline1975 and camtable, I read through this thread from late 2015...
I am also wanting to know best practice for getting the /32 evpn routes redistributed to the entire global routing domain to accomplish the desired efficient routing back to per-server/vm in the data centers.
I accomplished this by allowing the evpn L3 interface (irb.x) to remain in inet.0... which causes the evpn routes to automatically show-up in inet.0 table. And in order to get those evpn /32 routes sent to other global routing (inet.0) neighbors, I simply did an ospf export policy matching and allowing protocol evpn. seems to be working ok. I just want to know if this is the best practice for distributing evpn /32 routes into global routing domain.