Verifying MAC VRF – Isolated Tenants External Interconnect Route Leaking

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 10.1.1.1 and vni of 5020

1:24 host 3 uses VLAN and v20 IP of

1:28 10.1.2.3 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 10.1.1.254 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 8.8.8.8 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 10.1.1.1 so that's host one going to

11:54 8.8.8 perfect and then host or the host

11:57 of

11:58 8.8.8.848 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 8.8.8.8 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 10.1.1.1 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