Zach Gibbs, Content Developer, Juniper Networks

Verifying MAC VRF – Isolated Tenants External Interconnect Route Leaking

Learning Bytes Data Center
Zach Gibbs Headshot
The still image is a screenshot of the MAC VRF verification process on a desktop computer. It’s a black computer screen with white code from top to bottom. Part of the parameters have been highlighted in blue by the presenter, Zach Gibbs, Content Developer, Juniper Networks.

Juniper Learning Byte: Zach Gibbs on how to verify MAC VRF

In this helpful video, Juniper’s Zach Gibbs walks you step by step through the process of verifying MAC virtual routing and forwarding (VRF) isolated-tenants external-interconnect route leaking. This video is most appropriate for users who are familiar with data center technologies. Also to note: This is the verification Learning Byte; there is a separate Learning Byte on MAC VRF configuration. Okay, let’s get started! 

Show more

You’ll learn

  • Why it’s important to verify MAC VRF 

  • An example of the topology required for the verification process 

Who is this for?

Network Professionals Business Leaders


Zach Gibbs Headshot
Zach Gibbs
Content Developer, Juniper Networks


0:00 [Music]

0:09 thank you

0:11 hello my name is Zach Gibbs and I'm a

0:14 Content developer within Education

0:16 Services inside Juniper Networks and

0:19 today we will be going through the

0:21 verifying macro isolated tenants

0:24 external interconnect route leaking

0:26 learning byte

0:28 all right so here is our topology

0:30 there's a few things I want to point out

0:32 now keep in mind this is the

0:34 verification learning byte there is a

0:35 separate learning byte that goes through

0:37 how to configure this so we're just

0:39 focusing on verifying but I do want to

0:42 go through the topology and what we are

0:44 doing so kind of understand why we're

0:46 verifying it right so in this topology

0:48 we have a few devices here we have spine

0:51 one spine two Leaf one and leaf two

0:53 which are all a part of the IP Fabric in

0:56 our data center and the spine devices

0:58 are obviously acting as the spies the

1:00 leaf devices are acting as the Leafs and

1:02 then we have the Gateway router that has

1:04 connectivity to the internet that is

1:07 connected to leaf2 and then we have host

1:10 one and host three which are connected

1:13 to Leaf one and some parameters for them

1:16 is host one uses VLAN V10

1:19 IP address of and vni of 5020

1:24 host 3 uses VLAN and v20 IP of

1:28 and a vni of 5020 as well and

1:33 so how do things connect together well

1:35 host one connects into uh V10 verf which

1:39 is a Mac Verve and then the IRB

1:42 interface which is the layer 3 interface

1:44 for host one that is the default gateway

1:47 for host one that

1:49 address that's the default

1:51 gateway and then that is in the V10 VR

1:55 routing instance which is a Virtual

1:58 Router instance type

2:00 and then we have host three that

2:02 connects into v20 which is a macro and

2:06 uses IRB 20 as the layer 3 interface

2:10 well the default gateway which is then

2:11 in the v20 T5 routing instances which is

2:15 a

2:16 just a a verf that is a T5 uh routing

2:20 instance and then we have the common T5

2:23 verf which is on Leaf 2 which is also a

2:27 T5 routing instance and which is just

2:30 configured as a standard verf routing

2:32 instance and that connects into the v20

2:36 T5 verf as far as the vni and uh the

2:41 route Target and things like that so

2:42 those two connect together through that

2:44 and then we've set up route linking in

2:46 the previous learning byte that leaks

2:48 routes back you know between the V10 VR

2:52 routing instance and the v20 T5 routing

2:55 instance and there's some static routes

2:57 configured as well

2:58 and so with that being said let's go

3:02 ahead and jump to the CLI of leaf one

3:04 and leaf2 and get this going

3:07 all right so here is leaf one well

3:09 actually before we get going on Leaf one

3:11 let's actually verify that we have

3:13 connectivity with host one and host 3.

3:15 so host one let's see if we can ping

3:17 something on the Internet and we can

3:19 that's fantastic let's see if we can

3:21 ping host three

3:24 and great we competing host three

3:26 now something else I do want to point

3:28 out here is that with this setup

3:31 host one isn't going out to the external

3:34 router to get to host 3. that's

3:37 happening all on Leaf one so keep that

3:39 in mind you may want that or you may not

3:41 want that but that's how this current

3:43 setup does it

3:45 and so I'll ping just 8.8.8 leave that

3:48 running

3:49 and then let's see what we have here

3:51 let's ping

3:53 host three that looks great

3:56 and so then let's ping host one from

4:00 host three and that's working perfect

4:02 too so great we verified connectivity

4:04 that's really important we don't have

4:05 connectivity then we would have to go

4:07 and change a few things because it

4:09 definitely wouldn't be working all right

4:10 so let's go to lease three here and

4:12 let's delve into this verification a

4:15 little more so first I Look to look at

4:17 the bgp summary command look at the

4:20 output there to kind of give an idea of

4:22 what's going on uh the first two bgp

4:24 sessions are for the underlay so we can

4:25 ignore that for our purposes and then

4:28 the next two sessions are the spine

4:30 devices the sessions we have for the

4:32 spine devices those are route reflectors

4:34 and so we can see what we're getting

4:36 here we can see the bgp evpn.0 table has

4:39 one active route and then that active

4:42 route is also present in the

4:45 v20t5.evpn.0 route table so let's look

4:47 at those routes let's look at the show

4:48 route

4:49 uh table let's look at the v20

4:52 underscore T5 actually I need to specify

4:55 table there v20 underscore T5

5:00 and we can see here that we have some

5:02 routes let's look at the the inet.0

5:04 table that's associated with that

5:06 routing instance here and you see a few

5:08 things first of all we're getting a

5:10 default route now where is that default

5:11 route coming from that is coming from

5:13 the Gateway router that is advertising

5:15 that default route to leaf2 then leaf2

5:18 advertises to leave form and so that's

5:20 how that's showing up and it's an evpn

5:22 route

5:23 and we'll take a look at Leaf 2 to

5:25 verify it from that perspective as well

5:27 now look at what we have here the next

5:30 route this is the subnet associated with

5:34 host one right and how are we getting

5:37 that into this route table because

5:39 remember host one is not connected to

5:42 this Mac Verve and so recall from the

5:45 configuration learning byte we're doing

5:46 route leaking so that's how we're

5:47 getting it in there and then we can also

5:49 look here and see that we have the

5:51 subnet for host 3 which makes sense

5:55 because that's connected to the v20 uh

5:58 Mac verf which is then the layer 3

6:00 interface which is irb20 here is in the

6:03 uh the associated T5 routing instance

6:05 and so that looks good there okay so

6:08 what else are we getting here let's

6:09 scroll down to the evpn table and we can

6:11 see here that we have those evpn routes

6:13 that is associated with those inet

6:16 routes that we were looking at so you

6:17 see the subnet for

6:19 host one that EVP route is associated

6:23 there

6:23 and then we see it for host three that

6:27 subnet as well and then that default

6:30 route so that's perfect that's exactly

6:31 what we want to see so then let's take a

6:34 look at the route table for the V10

6:37 underscore VR

6:40 inet and so forth tables

6:42 and I'll guess it is just the inet table

6:44 that is in here we need to look at since

6:46 it isn't participating in evpn or

6:48 anything right

6:49 Okay cool so what do we see here we see

6:52 that static route that we configured and

6:54 it's pointing to the v20

6:57 t5.inet.0 route table right so that's

7:00 how the traffic from host one is getting

7:03 into the

7:05 v20t5.inet.0 table

7:07 and then getting to host 3 and getting

7:09 to anything on the internet which is

7:11 going through the Gateway router so it's

7:13 important that that shows up like that

7:14 that looks good

7:16 all right so then let's look at the see

7:18 what we're advertising to the spine one

7:21 device which is one of the route

7:22 reflectors so show route advertising

7:25 protocol bgp

7:27 then the IP address or the that is

7:30 associated with the session

7:32 and then we see the bgp evpn table and

7:36 so that's going to have all the evpn

7:37 routes in it and what we want to look at

7:40 here is we want to look at the type

7:42 fiber outs you can see here that we are

7:43 advertising the first we see here we're

7:47 advertising the route the evpn route

7:49 which is a type 5 route

7:51 you see that with the five here on the

7:52 side we are advertising that to the

7:55 route reflector for the host one subnet

7:57 and then you can see what we're

7:58 advertising here for the host three

8:00 subnets we are also advertising that to

8:02 the right reflector perfect that means

8:04 that the route reflector is probably

8:05 going to advertise that reflect that to

8:08 Leaf two so that's great and so

8:11 what else do we want to look at here we

8:12 look at the v20 T5 routing instance here

8:15 at the bottom and you see the same thing

8:16 here because

8:18 the evpn the the uh what is that route

8:20 table the

8:22 bgp.evpn.0. table just Aggregates all

8:25 the evpn routes the bgpe VPN routes

8:27 there so we can see the same thing in

8:30 the v20 T5 ebpn.0 table see the route

8:33 Associated the type 5 route that is

8:35 associated with host one subnet and then

8:38 the type 5evpn route associated with the

8:41 host 3 subnet so perfect that's what we

8:43 want to see there so let's go ahead and

8:45 jump to Leaf two on here on Leaf two

8:47 let's do the show of bgp summary command

8:49 and you can see here that

8:52 we are receiving two routes from the

8:56 route reflector and that's because we're

8:58 advertising two routes from Leaf one and

9:00 then the route reflector which is fine

9:02 one here is reflecting those routes to

9:04 Leaf two and so that's great so let's

9:07 look at the route table

9:09 show route table and for the common T5

9:13 route table and let's look at the inet

9:16 route table here we can see that we are

9:18 getting a default route and recall from

9:22 the configuration learning byte that the

9:25 bgp

9:26 session is in the main routing instance

9:28 so we use route leaking to get that

9:30 default route into the common

9:32 t5.inet.0 route table so that's why

9:34 that's there and then we have the two

9:36 routes associated with the or that

9:39 represents the host one and host three

9:41 subnets that's here because we advertise

9:43 those from Leaf one as type 5 evpn

9:47 routes

9:48 and so that looks good and then we

9:50 scroll down we can see the same routes

9:51 in the evpn table that is the

9:54 commont5.evpn.0 route table and we can

9:57 see here that this is the route for the

10:00 host one subnet this is the route for

10:03 the host 2 subnet and then we have the

10:05 default route as well in that table

10:07 that's perfect that's exactly what we

10:09 want to see and so then with that let's

10:13 look at what we're advertising to the

10:15 spine one device

10:17 bgp then 180 168.100.1 which is the

10:20 loopback address for spine one and you

10:23 can see here we are advertising the

10:25 default route and the bgp evpn.0 and the

10:29 common T5

10:30 evpn.0 route tables so that's perfect

10:33 it's type 5 route we are advertising

10:34 that and that's how Leaf one is getting

10:37 that default route and then let's see

10:39 what we're actually setting towards the

10:42 Gateway router

10:45 and you can see here that we are sending

10:48 some some routes that are associated

10:50 with the loopback addresses we could

10:52 filter those out doesn't hurt anything

10:54 to not filter them out but we could do

10:56 that but the important thing is that

10:57 we're sending the two routes that are

11:00 associated and represents the host one

11:02 and host three subnet so perfect and so

11:05 then let's go to the Gateway device and

11:08 here on the Gateway device we can do the

11:10 show bgp summary we can see here that we

11:13 have one bgp session and we are

11:15 receiving five routes perfect and then

11:18 let's do the throw route protocol bgp

11:22 and you can see here that we are

11:24 receiving those bgp routes and most

11:26 importantly the routes that are

11:28 associated with host one and host three

11:31 that's great and then something else I

11:33 want to show since this is an SRX device

11:35 that I'm using as the Gateway router we

11:37 can look at the session flow table

11:38 that's really cool because we can see

11:40 how things are happening so we can do

11:42 the show security flow session protocol

11:45 icmp since we're just doing a ping

11:48 and you can see something here so what

11:49 do we see here we see

11:51 so that's host one going to

11:54 8.8.8 perfect and then host or the host

11:57 of

11:58 there responding to this

12:02 address and the reason why you see this

12:03 172 25 11.31 is because sourcenet is

12:06 going on and so

12:08 don't worry about that just know that

12:10 this is the flow and things are going

12:11 good there now notice how the rest of

12:13 these are all for the host one pinging

12:16 out to recall that with host

12:21 three we left the Ping running here you

12:23 can see this here that is pinging

12:25 and so recall that earlier I

12:29 said that host one

12:30 is able to Ping host three and host

12:32 three is able to Ping host one without

12:34 going through the Gateway uh router and

12:37 so that is might be something you want

12:39 might be something you don't want but

12:41 keep in mind that's how that works there

12:42 and that is why we're not seeing that

12:44 session that is coming from host 3 to

12:46 host one on the Gateway router because

12:48 it's not making it out to the Gateway

12:50 router so keep that in mind if you are

12:52 using this solution

12:54 so that does bring us to the end of this

12:56 learning bite in this learning bite we

12:57 demonstrate how to verify isolated

12:59 tenants with an external interconnect

13:00 and Route leaking with Mac verf in a

13:03 data center so as always thanks for

13:05 watching

13:07 visit the Juniper Education Services

13:09 website to learn more about courses

13:13 if you are full range of classroom

13:15 online and e-learning courses learning

13:19 paths industry segment and Technology

13:21 specific training packs

13:24 Juniper Networks certification program

13:26 the ultimate demonstration of your

13:28 competence and the training Community

13:31 from forums to social media join the

13:34 discussion

Show more