Routing

Hi

From a demo I saw regarding EVPN.  I have seen that EVPN is created as a routing-instance.

this routing instance can have L3 interfaces defined to allow routing inside the EVPN instance to allow for optimal routing if the L2 part of the routing-instance  is spread over multiple sites.

If you want to allow access to one of these L3 networks from outside the routing-instance, normally you woulld perform route import/exports.

Does this work on EVPN?  Or to phrase the question another way.

how would you allow routing between the EVPN instance and the global table?

many thanks

Hi,

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.

[edit routing-instances EVPN] 
instance-type evpn;
interface ge-0/0/0.0;
routing-interface irb.10;
...

Having said this, you can assign the corresponding iRB interface to any layer-3 instance, e.g. a L3VPN or keep it in inet.0 where it is by default.

[edit routing-instances L3VPN] 
instance-type vrf;
interface irb.10;
...

Cheers,

Carsten

Hi

I was under the impression that the irb interfaces was included inside the routing-instance.

Is this the case ( ie does it work with ) VMTO features on the MX?

thanks

Hi,

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.

Cheers,

Carsten

Yes I understand the VTMO concept.

From the example you gave VTMO works in the egress direction.

Are the smarts there to advertise /32 host specific routes to make the ingress traffic optimisation as well?

if yes then how does this work if the irb interface is inside the inet.0 ( is there no difference? )

thanks

It also works for ingress VMTO. Have a look at the Whitepaper 

http://www.juniper.net/assets/us/en/local/pdf/whitepapers/2000596-en.pdf

started reading through the dayone book on EVPN.

it states on page:13

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:

[routing-instance evpna]

instance-type evpn;

routing-interface irb.xxx;

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?

thanks

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.

- Aaron