Prasad Miriyala, Principal Engineer, Software, Juniper Networks

Juniper Networks Network Isolation with Contrail Demo

Demo Drop Telco Cloud
Prasad Miriyala Headshot
Screenshot shows Prasad Miriyala in the bottom left corner giving his presentation. A still from his presentation is shown beside him on the right. The title of the slide is, “Namespaces and Networks.” Underneath the title is a diagram of K8s Cluster C1. It shows vertical boxes labeled Name Spaces and Isolated Name Spaces, and horizontal boxes labeled Default Pod Network, Virtual Network, and Default Service Network.

Live demo: Contrail network isolation made simple

In this detailed live demo of Contrail networking, Juniper’s Prasad Miriyala focuses on network isolation, policy and virtual network topology.

Show more

You’ll learn

  • Namespace and isolation concepts - and why they matter 

  • Network policy step by step 

  • An example of the virtual network topology 

Who is this for?

Network Professionals Security Professionals


Prasad Miriyala Headshot
Prasad Miriyala
Principal Engineer, Software, Juniper Networks


0:09 hi everybody my name is prasad i would

0:11 like to introduce three things here one

0:14 is the namespace isolation next is the

0:16 network policy

0:18 and the virtual network topology

0:22 so as michael mentioned earlier quest

0:25 when we create a cluster

0:27 typically we have a pod network and

0:29 service network

0:30 so we are calling that as a default pod

0:32 network and default service network

0:35 so all default part network on the

0:38 regular name spaces

0:39 when the pod is created it will be

0:42 working with this default part network

0:45 and the same thing if when we create a

0:46 service it's going to use the default

0:48 service network

0:50 so

0:51 as larry and others were asking earlier

0:54 like you know when we have the network

0:55 these networks are nothing but virtual

0:57 networks

0:58 which are based on the bgp

1:01 and uh each of this virtual network uh

1:03 would have a route target

1:06 uh you know when we create a virtual

1:08 network what we do is like you know we

1:09 have a export route target let's say rt1

1:12 and the import route target rt1

1:15 so so what that means is when we are

1:17 exchanging the routes for a given

1:19 virtual network

1:21 we will export with that route target

1:23 and

1:24 same thing when we import it we import

1:27 with that target

1:29 so

1:30 now if you see here we also can create

1:33 additional virtual networks

1:35 and

1:36 these virtual networks are not typically

1:38 connected until you know we use other

1:40 constructs to connect them using uh

1:43 import export

1:45 route targets

1:47 so so i will also demonstrate like you

1:49 know how we are going to control this uh

1:52 connectivity between virtual networks

1:54 so now given this namespace and you know

1:57 the basic power networking virtual

1:59 networks

2:01 i wanted to introduce this isolated

2:03 namespace

2:04 isolated namespace means like you know

2:06 we are trying to isolate that namespace

2:08 the pod network connectivity service

2:11 network and the uh any other virtual

2:13 networks

2:14 so that means

2:16 it's all internal and you know it can go

2:18 outside world towards to the you know

2:21 internet but

2:22 it won't be interacting with the other

2:24 isolated namespaces

2:27 you could do this with the you know

2:29 network policies but you know it's going

2:30 to be pretty cumbersome to do with that

2:36 so so let me go back to a

2:40 demo on that

2:51 so so here i'm creating a regular

2:52 namespaces called ns1 and ns2

2:57 um it looks like i already created them

3:01 and so then you know uh the uh i'm

3:04 creating the two parts on that uh

3:07 those isolated uh sorry those namespaces

3:12 after that like you know i'm creating

3:14 isolated namespaces

3:17 and creating two parts

3:22 so so as you can see here i have

3:25 two parts which are part one and part

3:27 two which are in ns1 and ns2 namespaces

3:32 and the other parts which are uh you

3:34 know iso uh a part isolated one iso iso

3:38 one in isolated namespace

3:40 isolated two is an isolated namespace

3:42 too

3:44 now

3:45 if i wanted to

3:47 cuddle exec minus i t

3:54 so i wanted to communicate between

3:57 test part one

4:00 which is in the regular isolated

4:02 namespace

4:10 link to the other

4:12 part which is in the other namespace

4:17 so i would be able to communicate or

4:18 vice versa

4:24 so so whereas if i go to the isolated

4:26 namespace parts

4:28 you know which is uh

4:33 so i'm bringing from

4:37 isolated namespace 1 to isolated

4:39 namespace 2.

4:42 and

4:43 you know the thing won't go through

4:44 because they are in two different

4:46 networks

4:47 and until they are connected you know uh

4:50 the

4:50 communication won't happen

4:54 so so this is uh the isolated namespace

4:56 concept

4:58 and the next one i wanted to demonstrate

5:00 is the network regular network policies

5:04 so as you see here i'm creating uh three

5:06 uh different uh tiers you know web

5:09 apptair and you know db tier

5:12 my network policies uh

5:14 uh you know this is a regular kubernetes

5:17 network policies

5:18 to show that like you know we work in

5:20 the application base to firewalling

5:23 so here i have three network policies uh

5:26 one is connecting between web to app and

5:29 app to db

5:31 so

5:32 because of this you know i should have

5:33 only communication between app to app

5:35 and app to db but not from you know web

5:38 to db

5:39 and if i don't have these network

5:41 policies you know i would be able to

5:42 communicate freely because uh there are

5:45 no network policies

5:46 so so let me uh

5:48 show that

5:50 so here as you see here i have um you

5:53 know network policies which are three

5:55 network policies

5:56 web tier app tier and db tier and also

6:00 you know there are three parts running

6:01 in the same default name space

6:09 so i'm going to take from part one

6:14 and try to communicate with part 2 which

6:17 is the

6:18 app web to app

6:28 and

6:29 so now i will try to communicate to the

6:31 db which is uh you know it should not

6:35 happen because you know we have the

6:36 network policies which are preventing

6:37 the traffic

6:40 and whereas if i go to part um

6:43 you know which is the web par sorry app

6:45 pod then i should be able to reach to

6:48 the dbe

6:50 and

6:52 if i remove the network policies

6:56 and i should be able to do the

6:58 communication between uh

7:00 you know any any to any

7:02 uh hence you know i have the

7:04 communication path

7:07 so

7:08 so this is a regular network policies uh

7:11 you know i just wanted to demonstrate

7:13 that

7:14 sorry prasad if you don't mind real

7:15 quick i think on that network policies

7:17 what's what's really interesting there

7:19 is also the way that we implement that

7:21 right is based upon some of those tags

7:23 um so you're not having to go through

7:24 and define by ip address right it's uh

7:26 it's really based upon the tags to to

7:28 define that policy

7:31 layers and layers in nicely too with the

7:33 name space isolation

7:35 that prasad kind of kind of walked

7:37 through initially you may ask yourself

7:39 kind of like well kubernetes provides

7:41 name space isolation right like what's

7:43 different here and really what's

7:45 different is that it's not done at a

7:46 networking layer um it's up to the cni

7:49 to do that so uh contrail is a cni we're

7:51 providing that segmentation for name

7:53 space isolation down to the networking

7:55 layers that's going to help prevent

7:56 things like lateral attacks uh some of

7:58 those types of scenarios you know if one

8:00 of your isolated pods for example

8:02 uh did get compromised when you have

8:05 name space isolation all the way down in

8:06 the network

8:08 that's correct so and just to add on on

8:10 top of what sean mentioned is uh

8:13 so so the v router when it implements we

8:16 use the tag based uh uh you know

8:18 comparisons instead of ip addresses

8:22 and also what that means is like you

8:23 know these stacks are exchanged through

8:25 the bgp

8:26 so for example as the let's say i have i

8:29 bring up a part called webpart

8:31 and which is tagged with you know tier

8:33 equal to web

8:35 and when we are exchanging this route

8:37 for this particular uh you know part

8:40 with tagged with the web

8:42 in addition to sending the route we also

8:44 send the tags along with it

8:46 in the uh bgp

8:48 so that makes it you know pretty

8:49 scalable and it reaches to the all the

8:52 other uh you know we routers

8:54 and all we're going to do is we're going

8:56 to use the tag id to do the our

8:58 comparisons so it becomes you know

9:00 pretty efficient uh

9:02 you know and pretty scalable

9:04 at the um you know we routed data path

9:07 layer so we don't have to have the

9:09 indirections uh

9:11 uh you know like ip tables or any other

9:13 things

9:14 yeah that's a great point two percent

9:16 because because we just you know you

9:17 just declare that through the ml files

9:19 so we go ahead and conceal the

9:20 complexity under the hood of handling

9:22 that between vgp

9:24 yeah great point so

9:27 so so the other area i i mean i wanted

9:30 to introduce is the virtual network

9:31 topology or the virtual network routing

9:34 so so as uh you know

9:37 michael demonstrated like you know we

9:38 have multiple clusters like you know a

9:42 virtual network which is a default

9:43 depart network in cluster one and you

9:46 have another uh uh default port

9:48 networking cluster two

9:50 so right now to communicate among those

9:53 we have constructs called like you know

9:54 a mesh network if we want you know we

9:56 can create a mesh network between

9:58 clusters

9:59 or this doesn't have to be across

10:01 clusters this could be inside a cluster

10:04 and same thing you know we have another

10:06 construct where like you know hub and

10:07 spoke relation between the virtual

10:09 networks

10:10 so what it gives you is the very

10:12 additional flexibility for the consumer

10:16 to do how these networks can be stitched

10:18 together

10:20 if you don't have this construct like

10:21 you know if everything is a flat network

10:24 you know it may not be advisable for

10:26 certain uh you know use cases

10:28 so that's where like you know we have

10:29 virtual networks using the bgp and you

10:32 know we stitch them as needed basically

10:34 so one is the you know mesh construct

10:36 other is the hub and spoke

10:39 so the big difference is like you know

10:40 when we have the you know mesh

10:42 everything is communicating to each

10:44 other

10:45 and when we have a hub and spoke like

10:47 you know hub hub and spokes can

10:49 communicate each other but not just

10:51 folks basically

10:53 all this is done through the uh you know

10:55 simple concepts like you know

10:57 using the rt import and exports

10:59 basically in a given virtual network

11:02 and everything is taken care by the bgp

11:04 constructs in the back end

11:07 yeah i think if i could add on to that

11:08 two percent the nice part here right

11:10 think about like your hub being some um

11:13 some common services that you want to be

11:15 able to support to these different spoke

11:17 uh virtual networks

11:18 but really the key takeaway here is that

11:20 the hub is non-transitive

11:22 right so you still have segmentation and

11:25 isolation done to your spoke virtual

11:26 networks um however you can you can also

11:30 you don't have to replicate services

11:31 within each one of those right you can

11:33 basically tie in some services into your

11:35 hub

11:36 that need to support the various

11:38 different spokes so it gives you that

11:39 layer of isolation

11:41 again down to the network level and that

11:43 can be applied across you know

11:45 multiple different environments whether

11:47 that's you know on-premises cloud what

11:49 have you um

11:51 all all with control so

11:53 so let me demonstrate that

11:58 so i have a namespace called

12:02 testns

12:03 and in here i have

12:05 created two labels for each virtual

12:08 network

12:10 one label is to create a vnr1 vnr1 mesh

12:12 other label is like you know vnr2

12:15 with a hub and spoke

12:17 so first let me create a

12:19 you know

12:20 you know mesh network and you know try

12:22 to ping each other so before that like

12:24 you know let me

12:27 uh show the parts which are in these uh

12:29 three networks

12:31 and cube cattle

12:33 get uh

12:35 vlr

12:36 minus and test ns

12:39 so i don't have any vnr's uh created um

12:42 uh here

12:44 so what that means is uh uh as you see

12:46 here test part 2 belongs to vn2 3

12:49 belongs to vn3 and 4 belongs to vn4

12:52 if i try to communicate among those

12:55 it it won't work because they are all

12:57 isolated virtual networks

13:06 actually let me have uh

13:08 why you're doing that prasad too i think

13:09 like you know the nice part about this

13:11 is like that default behavior of having

13:13 that isolation between your virtual

13:14 networks

13:16 it's a little bit of a different method

13:18 when you're when you're turning around

13:19 and deploying these uh these networks

13:21 for your kubernetes environment with

13:22 control right just gives you uh by

13:24 default um each one of those are gonna

13:27 provide this level of isolation from a

13:29 virtual network perspective

13:31 um and then you can declare where you

13:33 want connectivity

13:35 easily

13:37 as deans and kind of fits your

13:39 organizational policy

13:41 you may have different applications for

13:42 different uh different use cases some

13:45 things maybe internal other things may

13:46 be like external facing applications

13:49 as well

13:51 i have a question uh regarding the

13:54 assignment of virtual networks and what

13:55 the boundaries are um

13:58 if you want to assign something to a

14:00 virtual network is that done at the name

14:01 space level is that done at the pod

14:03 level um and can these virtual networks

14:06 i guess they can span clusters am i also

14:09 understanding that correctly

14:11 yes so basically when you create virtual

14:13 networks

14:14 uh it is you know under the name space

14:17 you can create

14:18 or you can create

14:21 at the higher level at the cluster level

14:24 so

14:25 if you see into the beginning uh

14:28 you know i we have a default part

14:29 network so which spans across multiple

14:32 namespaces

14:34 and whereas um you can create a virtual

14:36 network inside a namespace

14:38 uh you know as we are showing it here

14:41 and the other construct which you are

14:43 asking is among clusters

14:45 uh

14:46 you know we if it is a kubernetes uh i

14:50 mean if it is a cn2 cluster we can

14:52 create across the clusters but if you

14:55 have a c multiple c cn2 different

14:57 clusters as michael shown

14:59 then you know we use the connectivity

15:02 between these networks uh cluster one to

15:04 the other cluster

15:06 using the uh

15:07 one of the constructs which we are going

15:09 to use either mesh network or the hub

15:11 and spoke just to conclude on that yes

15:14 we definitely can span

15:16 a virtual network across clusters it

15:19 basically means what what do you what do

15:20 you mean by spanning so we can create

15:23 one layer two domain across multiple

15:26 clusters

15:27 serving the same

15:28 ip address of the same subnet across

15:31 clusters

15:32 the only thing you need to do is because

15:34 the ipaddress assignment is not going to

15:36 be synchronized but what we support is

15:38 in the subnet we can define a range out

15:42 of which we will assign ip addresses

15:45 to the pots so basically you can say

15:48 on my first cluster i'm going to use

15:51 dot one to 100 on my second cluster i'm

15:54 using 101 to 200 on my third cluster i'm

15:57 using 201 to

15:59 uh yeah 255 or 250 for depending on your

16:02 subnet size

16:03 um but the workloads themselves they

16:06 will think they are in one hugely true

16:09 domain so they can communicate

16:11 using uh normal layer two lookups

16:14 that is true or if you choose to have

16:17 each cluster has its own virtual default

16:19 virtual network and connect them also we

16:21 can connect

16:23 okay and any pod that gets created in a

16:25 name space that has a virtual network

16:28 will automatically be part of that

16:29 virtual network or is that something you

16:31 have to assign at the pod level

16:33 you have to assign that at the pot level

16:35 so per default the pod is

16:38 created in the default port network if

16:41 that part is part of a isolated

16:43 namespace it is going to

16:45 be created in the isolated namespace

16:48 default port network

16:50 which is different from the normal

16:52 default port network but if you want

16:54 then to even connect that pot to a

16:56 non-default port network so let's say

16:59 you want a secondary interface on your

17:00 port or third interface or fourth

17:02 interface you have to configure that on

17:05 the pod level so you need to tell the

17:06 pod as part of the annotation using the

17:09 network plumbing working group style

17:12 connect me a second interface or third

17:14 interface to a given virtual network

17:17 and just uh just to add at the the

17:19 distinction between

17:21 pod network assignment um at a pod level

17:24 or a name space level sorry um that

17:26 makes sense when you're when you're

17:28 isolating a set of workloads so

17:29 basically i want this whole set of

17:31 workloads to have their own virtual

17:32 network and to be kind of jailed off

17:34 from the rest of the pods but from the

17:36 pods perspective

17:38 it has a normal pod network connection

17:39 it has a normal service network

17:41 connection it just has its own little

17:42 copy of it

17:43 and then for multi-interface workloads

17:45 or whenever you're creating these

17:46 arbitrary virtual networks you want that

17:48 to be on an interface by interface basis

17:50 because you'll have like a network for

17:52 say inbound internet traffic and a

17:54 network for you know outbound

17:56 um services traffic or something you're

17:59 basically recreating a multi-interface

18:01 server using these network attachment

18:03 definitions within each cluster you've

18:05 got a virtual router that's handling

18:08 communication between the virtual

18:09 networks

18:11 um

18:12 is that also part of the architecture

18:14 yeah uh contral actually has a

18:15 distributed virtual router so the

18:17 routing takes place on every node in the

18:19 cluster so the the concept of the router

18:22 is logical it's it's everywhere in the

18:23 cluster so it's running as like a daemon

18:25 set on each each node in the cluster

18:31 and is there an opportunity to insert

18:33 firewalling and

18:35 you know rules of communication between

18:37 subnets

18:39 yeah there's a couple ways that we do

18:40 that network policy is the way that we

18:43 create firewall filters inside

18:45 kubernetes to filter out traffic and you

18:47 saw a little bit of that during prasad's

18:49 demo and then also we have another

18:51 construct that allows you to create

18:53 very flexible import and export policies

18:55 and a per prefix basis between all of

18:58 the virtual networks

18:59 so you've got a big stick and then

19:00 you've got the scalpel as well

19:02 okay

19:03 thank you

19:04 thank you

19:05 okay so so here

19:08 in this

19:09 use case we have created three parts

19:12 and as you see here

19:14 there are two interfaces for this part

19:17 one is in the default part network other

19:19 is in the test vn2

19:21 test vn3 and test pn4

19:23 so right now what we have done is uh

19:26 you know if i try to ping between this

19:30 the secondary interface which is the

19:31 test vn2 3 and 4

19:34 that communication won't happen because

19:36 there is no uh you know virtual network

19:39 router which is connecting them

19:42 so that work and i'm trying to do the

19:44 ping test between test part vn2

19:47 to vn3 rbn4

19:55 so i'm going to create a mesh network

19:58 control create minus f

20:01 test vnr mesh

20:07 so now the same ping test would go

20:09 through because um you know we have

20:11 created a mesh network

20:13 what that means is the each virtual

20:15 network is going to do the

20:18 import and export route targets

20:21 uh to the same route target so that the

20:23 mesh communication happens

20:26 and so i would like to demonstrate the

20:28 other

20:29 option which is the hub and spoke

20:36 so so with this like you know what we

20:38 have done is uh you know we have one hub

20:40 and you know two spokes which is vn2 is

20:43 the hub and you know vn 3 and 4 are

20:46 spokes

20:47 now i'm going to do another ping test uh

20:52 so so in this here like you know we are

20:54 doing um you know how to spoke

20:56 communication

20:57 then after that like you know we are

20:59 trying to do a spoke to sport

21:00 communication you know which should not

21:02 happen

21:03 uh because

21:04 that's what is the intended uh here

21:07 so all we are doing here is like you

21:09 know we have virtual networks using the

21:11 route targets to manipulate the way we

21:13 want whether we wanted to have one

21:15 direction communication

21:16 or bi-directional communication or

21:19 coming

21:20 having a communication among all the

21:22 virtual networks

21:24 so

21:25 so now so far what we have shown is uh

21:28 how to isolate an namespace

21:30 then regular kubernetes and network

21:32 policies and the third is like you know

21:34 how do we connect the virtual networks

21:37 so that they know we can communicate

21:38 each other at the network level

21:41 and also another key takeaway is the in

21:43 the network policies the way our

21:45 implementation is uh we use the tag

21:47 based uh

21:48 uh you know implementation at the v

21:51 router level so that it's you know

21:53 pretty fast and uh

21:55 and also we use the bgp to exchange

21:58 these

21:59 tags

Show more