[j-nsp] evpn with vrf

[James Bensley]

On Wed, 16 Jan 2019 at 02:29, Aaron Gould <aaron1 at gvtc.com> wrote:
>
> I wanted to share some thoughts and new experiences with you all,
>
>
>
> I've been learning evpn in the lab in preparation for using it to connect a
> couple data centers.  I think this would be known as evpn-mpls (and not
> evpn-vxlan, as I've heard "evpn-vxlan" mentioned in the same breath over and
> over and over again in video's, conferences, etc. I began thinking evpn
> didn't exist apart from the acronym "vxlan" but I'm pretty sure I understand
> that vxlan is only one of a few different data planes that evpn can make use
> of.. mpls, pbb, vxlan)
>
>
>
> I think the evpn flavor I'm working with is known as "vlan-aware bundle
> service" where you use routing-instance instance-type virtual-switch with
> subordinate bridge-domains.I've also followed a book I was reading and added
> a routing-instance instance-type vrf with the irb inside both routing
> instances (this irb seems to be an integral part of the "glue" that
> integrates these two instances together)
>
>
>
> On the PE-CE edge interface, where mac addresses are traditionally learned,
> I'm blown away at how evpn-learned mac addresses are automatically copied
> into the vrf routing table as /32's and then of course once there, auto
> exported using basic vrf route-targets. then the remote vrf-only pe's have a
> /32 absolute way back to the host at the exact dc evpn pe where it was
> advertised.
>
>
>
> .I've read something about this a few times, but to see how it works is
> eye-opening.
>
>
>
> I have more to learn I'm sure.  If you have anything to add, I'm all ears
> ..or, eyes, you know : )

Hi Aaron,

Sorry for the late reply. Ah, I didn't know this had a fancy
name:"vlan-aware bundle service", thanks.

We've used this before and yeah it does work surprisingly well, if
feels a bit wrong but we've had this with thousands of MACs | /32s per
EVPN/VRF instance and it just works. The only "gotchya" I've
encountered so far has been due to interface flapping. We had some
thousands of MACs and / 32s hanging off a PE interface, when that
interface flaps, it causes quite a large amount of updates to the FIB
on that local PE and across all PFEs in the chassis, it would actually
impact traffic on other interfaces on the same PFE (i.e. BFD/IGP/BGP
sessions flapped) and sometimes traffic on other ports in other line
cards (and those cards would log a couple of PFE timeout errors and
then recover).

To be clear (a config is worth one thousand words), I think this is
what you're referring too, this is what worked for us, if you've got
something different please share:

set interfaces xe-2/0/5 unit 1130 description "Foo VLAN"
set interfaces xe-2/0/5 unit 1130 family bridge interface-mode trunk
set interfaces xe-2/0/5 unit 1130 family bridge vlan-id-list 1130

set interfaces irb unit 1130 description "Foo Gateway"
set interfaces irb unit 1130 family inet address 10.0.0.1/24

set routing-instances Foo-EVPN-VLAN instance-type virtual-switch
set routing-instances Foo-EVPN-VLAN route-distinguisher 12345:10
set routing-instances Foo-EVPN-VLAN vrf-target target:12345:10
set routing-instances Foo-EVPN-VLAN interface xe-2/0/5.1130
set routing-instances Foo-EVPN-VLAN protocols evpn extended-vlan-list 1130
set routing-instances Foo-EVPN-VLAN bridge-domains vlan-1130 domain-type bridge
set routing-instances Foo-EVPN-VLAN bridge-domains vlan-1130 vlan-id 1130
set routing-instances Foo-EVPN-VLAN bridge-domains vlan-1130
routing-interface irb.1130
set routing-instances Foo-EVPN-VLAN bridge-domains vlan-1130
bridge-options interface xe-2/0/5.1130

set routing-instances VRF-Foo instance-type vrf
set routing-instances VRF-Foo route-distinguisher 12345:20
set routing-instances VRF-Foo vrf-target export target:12345:20
set routing-instances VRF-Foo vrf-import Foo-IMPORT-RT
set routing-instances VRF-Foo vrf-export Foo-EXPORT-RT
set routing-instances VRF-Foo vrf-table-label
set routing-instances VRF-Foo interface irb.1130

Cheers,
James.