Jumpstart Juniper—Switching

0:01 welcome to jumpstart Juniper's switching module here we're going to talk about uh

0:07 switching in different Hardware that we have so go ahead let's go ahead and get started

0:15 so let's just go over some of the basics of switching so we make sure we understand how it all works

0:22 we used to have a shared Lan and we'd have what we call the Hub that hooked

0:27 the machines together and this Hub just moves signals from one port to all the

0:33 other ports on the Hub so if user a sent traffic out to the hub users B and C got

0:41 the traffic now this was not good for security reasons because all your

0:46 traffic ended up everywhere in the network so you could put a sniffer out on a on one of the ends and be able to

0:53 see all the traffic going through the network so they came up with a new system

1:00 this was a switched system the switch system learned Mac addresses and

1:06 basically made each wire its own Collision domains so user a when user a

1:13 talks to user C the traffic goes from a to c and does not go down to user b or

1:19 any other users on that switch because it finds out the two Mac addresses and just pushes the traffic towards the Mac

1:26 addresses each way so how does this bridging or switching

1:32 work well it works by maintaining tables uh and it gets these Tables by these

1:39 five mechanisms that we'll talk about here learning forwarding flooding filtering and aging

1:45 the first mechanism is learning so we need to be able to learn the Mac

1:51 addresses that are on our Network and so what it does is it listens as as

1:56 broadcasts go out to find out where certain Mac addresses are coming into

2:01 the switch at and if they're coming in from one of the interfaces then it knows if it needs to talk to that Mac address

2:08 is going to have to send out the data down that interface

2:13 so here we show that that as we go through the source address of these uh

2:18 packets are being learned and as they come through it'll sit there and fill out the the MAC address table so once

2:26 we've learned the Mac addresses we move over to forwarding so now we

2:32 know when we get a a frame or a packet from a certain Network trying to go to a

2:38 destination address we can look up where that destination address is and forwarded out that interface

2:48 so here we see we have a bridging table that's set up with different vlans and

2:54 we create uh the the forwarding table based on VLAN so if we have vlans in our

2:59 Network we're going to separate those all out per VLAN

3:05 what incomes when we're not sure where the address is at if we get a request

3:11 for a certain Mac address and we don't want to know where that Mac address is we'll flood out every interface to

3:17 hopefully get a response back for that Mac address and so then we have flooding

3:22 and once we get a return then we'll know where that Mac address is at and we'll go ahead back into the learning mode and

3:28 put it into the table filtering uh we filter based on the

3:38 interfaces and so again we talked about that Hub where it a packet or a frame

3:44 would come in and we'd send it everywhere well now we know which

3:49 interfaces the the host is at that we're trying to get to and so we're going to filter it off any other interfaces that

3:57 don't have that Mac address and so here we see user a can talk to user D without

4:04 pushing it down to interface 7 down to the hub

4:10 and then of course we have an aging because we want to make sure if somebody unplugs their computer from there if we

4:17 haven't seen that address in so long we're going to age those off and get rid of them out of our table so our table is

4:23 nice and current uh because somebody could have pulled the the computer off one interface and move it to another

4:30 interface and so then we'd need to be able to make that move with that we'll

4:35 use that within aging with an inactivity timer

4:41 so here we have a topology we have a switch and a hub and so we have users a

4:47 b c and d hooked here and we have user B who sends out a message to user d

4:55 um and so what we want you to think about is where is this message going to go is it who's going to receive this

5:02 message if we send this out and we do see that it's going to be

5:07 [Music] um on it's going to go out from user B it's going to go to user C because they're on

5:14 a hub and then over to user D because they're on a switch but the switch will make sure user a does not get that

5:20 information these switches are usually built into a

5:26 hierarchical design so we got three layers normally a core layer an aggregation layer and an access

5:32 layer this creates a kind of a modularity so we can add to or remove

5:38 from a little easier it also breaks things down into different areas for

5:44 troubleshooting and for problems that might arise

5:50 so these different layers serve different functions the core layer is where we do our routing that's where

5:57 we're going to hand off to whatever main routing device that we have to move to a

6:02 Wan or another Network the aggregation layer connects these different

6:10 networks and does inter VLAN routing uh we also have these aggregation layered

6:18 switches in there because the interfaces on these devices are usually a little cheaper than the core devices interfaces

6:26 so we put the aggregation layer in there so we can have smaller core devices

6:31 the access layer facilitates where the end users connect to and where they

6:37 um or where they attach and where we have all the access policies for those

6:43 end users now as we move forward we're trying to

6:48 consolidate these layers uh the let the less layers you have the less problems

6:54 you have a spanning tree and other uh protocols and so we're trying to move

6:59 these in and so you can see we can take these layers and we have a virtual chassis fabric svcf here is what is is

7:08 displayed here and so we try to move it into this other system to break down

7:15 those um those layers makes it easier to configure and to maintain

7:23 so here's how we've kind of evolved we have this we've had these uh MC lag the

7:30 multi-chassy lags where you can have an interface from each side come down to a device and then the two devices talk to

7:38 each other to try and make sure that we we communicate correctly over those two devices and then we've moved to a

7:44 virtual chassis where the chassis all work as a single chassis but there's

7:50 multiple chassis in there we'll get to we're going to talk about that and then we have the virtual chassis fabric which

7:56 basically can expand out on the virtual chassis idea and and have a spine and

8:03 leaf kind of an architecture so that leads us into the layer two

8:10 Fabrics virtual chassis virtual chassis was

8:16 created for the ex series switches and the qfx series switches and they can

8:21 operate now as a single switch you can put up to 10 different devices together

8:26 and make them function as a single switch the switches don't all have to be

8:33 the same so you can mix and match different switches depending on what your needs are but not all of them can

8:39 be interconnected so you need to watch out for that and then all of those switches can be

8:47 hooked together with a single Uplink up into like say the core so that way you

8:54 don't need as many core interfaces as you used to because we have these virtual chassis that reside down there

9:01 so why do we want to have this it also gives us redundant routing engines and

9:06 so if we lose one of the routing engines another one will take over for us and we

9:11 can even set it up so if two of them die that another one would take over but hopefully you're going to get those fixed before you know you lose two

9:18 routing engines and so that's usually not a need for that but basically just

9:23 simplifies the network design we're gonna have a single configuration and a single management unit for up to 10

9:29 switches so you can build these a little bit differently

9:35 um we have different types of components that we use here and so here you see we

9:41 have our virtual chassis ports which are on the back those are dedicated ports

9:46 but we can also use the the one or ten gig ports on the front with our normal

9:53 interfaces and connect the devices together which we see here in the orange lines and that way we can push those off

10:00 a little further maybe we can put one in each building or one in each rack and we can push the the the actual Stacks a

10:06 little further away from each other but they still all look like a single device to the configuration and to the routing

10:14 engine so here's one of the wiring options here

10:20 we just have a daisy chain right if you follow that little blue line we go basically in a circle we have another

10:27 option here which is a braid and so braiding you can actually move the

10:32 device a little bit further away from each other if you need to a lot of people will put something like this in

10:38 the top of racks and usually the the furthest rack can't get back to the

10:43 first rack um in the in the first option and so we can braid them like this so we can push

10:49 those switches a little bit further apart or we can have this mixed ring method

10:55 where we have some that are on the dedicated ports and some on the 10 gig Uplink ports when we put these together

11:02 as a virtual chassis each of the chassis gets a member ID from 0 to 9. these

11:09 member IDs are preserved through reboots and moving them around if you unplug

11:14 them move them around plug them back in that same number will be assigned to that switch

11:20 um and so it serves as a slot number for our interface numbering also

11:26 here we have some interfaces in a virtual chassis and you see they're

11:31 highlighted in the orange and we're going we want you to know what are those interface numbers okay so here we have

11:38 one on member ID one and one on member ID three and remember we said on the

11:44 last slide that that member ID is also the slot number for the interface

11:50 so here we see we have ge100 and ge101 on member id1 and then

11:59 on member ID3 we have ge3046 and GE 347 so you can see how

12:06 that member ID is used for the the slot number for the switch

12:11 management is fantastic so we only need a single IP address to manage 10 devices

12:19 uh because they come together as a single device so you only have to manage the routing engine to make that work

12:25 that way the management interface is called a vme a virtual management ethernet interface

12:33 on these devices and so you can see here in the example we set up a IP address on

12:39 the vme and uh we can then we can manage that whole device we also have a virtual

12:46 console Port so if you need to plug into the console Port you don't have to look

12:51 for which one is the routing engine right you can plug into any of the console ports inside of the virtual

12:57 chassis and you will get the signal from the from the routing engine to be able

13:04 to communicate to and that's great in an emergency when you're running in trying to find it real quick you don't have to

13:10 find the exact switch that's acting as the routing engine

13:16 so there are some requirements and the first requirement that we're going to have is that all of the OS versions have

13:23 to be the same on all the member switches and so if you add a new switch

13:28 into a virtual chassis that's already there and that's a different version of

13:34 code the switch will go in and and everything will be fine but that switch

13:39 will be uh inactive and it will not pass traffic and so you need to then upload

13:47 the software and upgrade it to whatever version the stack is so that it could communicate there

13:53 so you could do that manually you do a little manual uh up upgrade on that

14:00 device request system software ad and then the member number and then it would add that or we can do it automatically

14:08 and doing it automatically is great because you basically upload the software package to the master routing

14:15 engine and then that routing engine will then if a new member comes in line it's

14:20 not their same code it will push the package down and upgrade that member automatically for you when we put these

14:27 switches into a virtual chassis the virtual chassis members use a protocol

14:32 called vccp to create a loop free topology to be able to pass a traffic

14:38 it's very similar to Isis routing protocol in which we're trying to find

14:44 the shortest path through the network these are trying to find the shortest path for each of their forwarding planes

14:51 inside of each of the switches to push traffic each one of the switches has up

14:57 has usually around three or more forwarding engines and so if you see down here we have the

15:04 different forwarding planes we have a b and c d e and f g h and I and we need to

15:10 find the shortest path between each one of those forwarding planes to another forwarding plane

15:16 and so what the protocol kind of does is it kind of breaks us into a loop and

15:22 puts those in there so very quickly we can find out from any one of the forwarding planes what is the shortest

15:29 path to the rest of the forwarding planes so here's an example if you're going from A to B C D or E you're going

15:37 to go down One path and if you're going to IH uh G or F you're gonna go down another path and then we're going to

15:44 grab and make a tree from each one of those planes to all the other planes so that as soon as we get a packet in and

15:51 we know which interface has to go out we can quickly pass it the right direction

15:57 so here's just some examples we have a packet come in on ge0010 and one on

16:04 ge0028 and we need to go out two different places and you see one is going to go around to the bottom switch

16:11 switch number four down at the bottom and one is going to go down to switch two one and switch two and then come out

16:17 so uh basically these are going to find the shortest path through the the

16:24 topology to get that packet out to the interface it needs to go to

16:31 all right now we have a quick virtual chassis demo for you in this demo we'll show you how to build

16:38 and tear down a virtual chassis system and we have two switches ex1 and ex2

16:45 will join together and ex1 will be our master switch we have a client that's connected to ex1

16:52 and a server connected to ex2 and they can currently talk to one another

16:57 we'll go ahead and form a virtual chassis and see how it changes the communications

17:04 we're going to start with ex2 here and do show virtual chassis status

17:09 to determine yes it's a standalone switch

17:15 look at the virtual chassis VC ports to look at what state they're in they're installed

17:21 but they are disabled this is not the default status so if you

17:27 buy a switch and hook them together they will try to form a virtual chassis

17:37 we disabled these so they'd have full control over when the adjacency would be formed

17:42 so just keep track of that so let's switch over to ex1 and verify its state

17:48 show virtual chassis we didn't have to put the status in

17:54 there because show virtual chassis is the default we're going to look at our ports here on

18:00 this switch and they're also disabled and this is why we're not in a virtual

18:05 chassis because both of our vcp ports are disabled so let's verify that we have

18:12 connectivity between the client and the server

18:17 so we'll do a ping 172 2311.100

18:23 from the routing instance client one and we do have connectivity

18:32 before we activate the virtual chassis there's a couple cans commands we need

18:38 to enter so let's go into our configuration mode the first one we need to check the virtual chassis membership

18:45 number mastership so we'll set this master shift priority to 255. this will

18:51 keep it as as the master the default value is 128.

18:58 than under virtual chassis again we're going to set no split detection junos has a way when there's virtual chats

19:05 with multiple members if there's a split between multiple members then they can't talk

19:11 junos will calculate which one has the most ports or which one is the most stable and choose that one to be the

19:18 master so we don't want both of the devices to go into Master mode

19:24 and with just a two node membership in this virtual chassis we need to put this

19:30 special command in here the no split detection to make sure that we don't get uh the the system will fail over

19:37 correctly and not both of them will turn into the master ship on both sides

19:43 the last command we're going to enter is because we sshed into the device and

19:49 we don't want to lose connectivity you're told to do this after the virtual

19:54 chassis is formed but we can also do it before so here we're going to do copy

20:00 interfaces me0 to vme

20:05 this is the actual virtualized management interface

20:10 and then we'll delete the me0 after that so because we have the same

20:16 IP address and we'll go ahead and commit that this is going to put us ready to start

20:22 our virtual chassis activation so now let's go over to our

20:28 configuration mode again our our operational mode and request virtual chassis vcp Port set

20:36 interface vcp-255 slash one slash zero

20:42 and that activates the port and will activate the other port so when we go in to confirm this

20:49 show virtual chassis vcp ports now the status is down because the other

20:57 switch has the interfaces disabled also so they

21:03 still can't talk so we'll go over to ex2 and activate those ports

21:10 we'll go ahead and activate the ports on ex2 now request virtual chassis VC Port

21:18 set interface vcp Dash

21:23 255 slash one slash zero

21:29 and the moment this happens the virtual chassis is going to start to be built if we go back over to ex1 and do a show

21:36 virtual chassis we can see that it's seen the other device it hasn't completed its work

21:44 show interfaces terse ge's asterisks

21:51 I only have the normal 24 ports in ex1

21:56 but if we do virtual chassis now now it's completed and discovered the other

22:01 switch and and so we have the backup roll in there

22:08 so when we go down to look at our interfaces now we have our ge0

22:13 interfaces to 23 we have our ge1 interfaces to 23 from the other switch

22:20 both switches are now acting as a single switch with a single configuration

22:27 so at the current time all the interfaces are down it's still exchanging information and

22:34 trying to sync both sides together the configuration from ex1 is being

22:42 copied to ex2 so they'll have the exact same configuration on the both switches

22:48 so if that's why if the main routing engine engine fails the its second

22:53 routing engine has the entire configuration

22:58 show interface turns now we see some of the interfaces are starting to come up

23:05 so our virtual chassis is formed let's take a look at our virtual chassis

23:10 both devices are there we have a master and a backup stove virtual chassis VC Port we can see

23:17 that both interfaces are connected and but we can see that only one of the

23:23 interfaces are connected the other one's still down because we've disabled the other one so let's request virtual

23:29 chassis VC port set interface

23:35 vcp 255 slash is one slash one and

23:41 member this is on Member One so we're going to put member one on there

23:48 so we wanted to execute on the other switch and now we go back and look and we

23:54 should see that they're all both up both interfaces

24:01 there we see that they're all up and running and the virtual chassis has formed

24:07 now at this point you can continue on if I try to make changes

24:15 and commit I'm I'm going to get an error so let's take a look at that so we jump

24:21 into configuration mode and let's delete interface ge001

24:26 [Music] and do a commit and now when I do this commit I'm going

24:33 to get an error because the system wants a reboot now to bring everything back so if you see

24:41 this all you need to do is reboot the devices to get rid of this error so that

24:46 the system knows about the virtual chassis so

24:52 so it did complete and work so we're going to go ahead and do a reboot now

24:57 and we'll join back after the reboot

25:06 okay our reboot is finished but before we go back into the actual devices let's

25:12 point out a few things ex1 and ex2 are now one device as far as

25:17 the system considers ex1 has all the ports from zero zero zero

25:24 two two one zero zero twenty three

25:29 all belong to ex1 so ge008 is still up and working to our

25:35 host but the configuration on ex2 is gone so we don't have that figuration

25:42 anymore so we need to go back in and configure ge008 to ge108 on ex2

25:50 so that we could get the server to connect back in and be able to work there we also would need to change all

25:56 the other configurations on ex2 if we had any connected to other devices

26:03 so let's go back to our terminal and

26:09 we're you're gonna ping we're gonna try a ping to the server

26:16 ping 172 23.11.100

26:24 and we see that we do not have a response from there because it moved from zero zero eight to one zero eight

26:30 so let's look at the configuration on one zero eight and we're going to see that there is no configuration so we

26:37 need to get a configuration on that interface to make it work so let's look at zero zero eight to see

26:43 if the client configuration is still there and we see that that is still there so

26:50 we could just copy that configuration over to the other interface so copy interface g0082 GE one dash one zero

27:01 eight and commit that and now we should be

27:07 able to communicate across there so let's go ahead and retry the Ping

27:14 let's notice one thing we don't get an error when we commit now and when we do see we see fpc1 come

27:23 through first with the commit complete and then you see another commit complete so in order to maintain connectivity the

27:31 system goes to the backup routing engine and commits on the backup routing engine first

27:36 to make sure the commit works and it won't so that we know that it won't have a problem with connectivity

27:44 and so then we come back under the master routing engine and do a commit on

27:49 the master routing engine this is kind of a safety measure that's there so we can go ahead and reach our

27:55 ping and now we have connection between the two switches so we see that the

28:00 virtual chassis is up and we have communication between there and now we can go ahead and configure all the rest

28:06 of the ports and it acts as if one single device across both devices so now

28:12 that it's working let's tear it apart so let's get out of there we're gonna we're gonna go ahead and

28:18 disable the ports so let's go into request virtual chassis

28:24 DCP Port set interface vcp Dash

28:30 255 slash one slash one disable member we're going

28:38 to do it on the other device first so that we stay in control

28:43 so we get number one down and then we're gonna disable the zero port on the other device

28:51 as these devices split both devices will have the exact same configuration on

28:57 them so on the second switch we're gonna have to go and change that configuration

29:02 so it doesn't have the same IP address for connectivity so

29:08 here let's go disable our Port so we're going to say request virtual chassis

29:14 VC port um set

29:21 interface vcp Dash 255 slash one slash zero disable

29:30 and the other one so do the one connection so now we can do a show virtual chassis

29:38 VC port oh I lost my connection so let me do

29:46 this show virtual chassis VC port

29:52 and we see that this inner the status is down and it'll take a little bit to show that

29:59 it'll be stable but it'll show that it it'll turn to disabled here in a little bit but we need to look at a few other

30:05 things when we do show virtual chassis we still see the member IDs are there zero and one

30:11 and we need to do a renumbering to get them all back to zero so they can be individual machines so we got a couple

30:18 extra commands to run so on this device we can do a request virtual chassis recycle

30:26 member ID one to free up that number one

30:31 on the other device though I'm going to have to have one active and so 0 will be

30:39 one so I need to go in and re do a request virtual chassis recycle member

30:44 ID 0 and then I need to change the member ID from one to zero using the

30:51 renumber command you you have to make sure these are fully cleaned up to be able to separate those out that's our

30:57 demo on Virtual chassis

31:02 let's talk about the virtual chassis fabric now this is a an expansion off the virtual

31:09 chassis and in this design we're going to build a spine and leaf architecture

31:15 this spine and leaf architecture allows for each of the leaves to direct connect

31:21 directly to each of the spines that we have now in this setup we can only have

31:27 a maximum of four spines and a maximum of 20 devices total within the network

31:35 we can use the qfx 5100s and the qfx 5110s to create this the spines and then

31:43 any of the switches there the 5100s 5110s the 3500s 4300s or 36 hundreds to

31:51 create the Leafs that we see here so let's look at this architecture just

31:57 a little bit more each of the leaf nodes they connect directly to each of the

32:04 spine nodes and so any of the the user interfaces are only two hops away from

32:10 any of the other devices this helps make a more stable Network for us as we are

32:16 trying to decide latencies and different things through our Network we know that any device is hooked to this system or

32:23 only two hops away from each other it creates a resilient network path where if we lose one of those hops

32:30 because we have a connection to each of the spines we'll just move over to the other spine and move across there to the

32:37 other switch so there is no physical connectivity between this the Leafs or the spines

32:44 themselves everything gets communicated back and forth through the the either the spine or the leaf so if the spines

32:52 need to talk to each other they'll send control communication through the Leafs to talk to each other

33:00 so in this scenario because we have four spines we have four distinct paths from

33:06 host a to host B that we could take and the switches are going to use a hashing

33:11 algorithm on the source destination information to figure out which path to

33:19 take because we always want to keep the the communication from one host to another host on the same path so that we

33:26 don't get packets out of order and so we want to make sure we hash put them all on the same network there

33:33 what are some of the benefits of using uh the virtual chassis fabric well you

33:39 get redundancy again we have our redundant routing engines the spines act as our routing engine so if you have two

33:46 you have you can have a master routing engine and a backup routing engine if we

33:51 need to go further than that you could if you had four then if you lose one one

33:57 of the other ones will then become a backup routing engine for you so we can also simplify some of our

34:03 other architecture we can push out as the spanning tree protocol if you design

34:09 it right and we can flexibly put these switches anywhere we want to and so you

34:16 can create a single switch throughout an organization if you only need of 20

34:22 devices what are some of these other benefits if we compare that to the virtual chassis

34:28 that we just learned about well we can go up to 20 devices instead of 10. we

34:33 can have a better fabric redundancy fabric we have better load balancing

34:39 across that fabric each of the devices are only two hops away instead of you

34:44 know we can have up to like five or six hops in the virtual chassis so we can do

34:51 a mix of 10 gig 40 gig and uh we can have more backup for our routing engines

34:59 so there are some similarities some of the similarities are the the member ID

35:05 is also the FPC or the slot number for our interfaces all of our console and

35:12 management um traffic is all pushed to the console

35:17 ports so we don't have to go find out where which one is active uh it's a very nice management system that way we're

35:25 going to still use that VCC protocol to figure out the shortest path for all of the devices inside of this vcp topology

35:35 um and so if if we have two or more local interconnects that exist between

35:40 the two nodes the interconnects are automatically placed into a lag and so we can have more load balancing and

35:47 better redundancy because of that so let's look at the devices that can do switching we have our SRX series Branch

35:54 devices our ex series devices and our qfx series devices all do switching and

36:02 so most of this uh informational work across all of these devices

36:08 with the same configurations because it's junos we have a separation

36:16 of the control plane and the forwarding plane and so the the control plane is

36:22 what gets all the information figures out how the package should flow where it should end up it makes a routing table

36:29 and a forwarding table it pushes that forwarding table and routing table down into our uh forwarding plane so that we

36:39 don't have to go back up and ask the routing engine when we need to move traffic any updates will be put into the routing

36:46 engine and then updated back into the forwarding table down below

36:53 the ex series switches have a management interface uh that management interface

37:00 uh is a uh an IP interface it's is an

37:05 me0 interface which is a little different because some of the routers have an fxp zero interface and the

37:12 switches have an me0 interface so it's the same thing uh just name just

37:18 a little bit different uh you'd configure an IP address on it and then be able to access that device so here we

37:25 see down here we see a little bit of a configuration with an IP address hooked to that management interface

37:35 so here we have a switch number one and we have three hosts hooked to this

37:41 switch and we want to configure this switch to be able to facilitate

37:46 communication between all of these hosts here user a b and c so let's go ahead and take a look at how

37:53 we could do that so the first one is we can individually

37:58 Define each interface so over on the left hand side here we see under interfaces we have our interface six

38:06 seven and eight for the three users we're going to add them into the

38:11 protocol ethernet switching family and when we do that then we can communicate

38:17 on layer 2 between these devices and if they have are all on the same subnet

38:22 then the layer 3 will go through also just it's a normal switching interface but junos allows us to do it a little

38:31 bit differently too we can do an interface range and so here we have an interface range where we can go ahead

38:38 under there under there we give it a name so here we have range-1 is our first range and then we can do a member

38:45 range and we can just say ge006 to ge008 and then we can say unit 0 and put it

38:51 into family ethernet switching now that's great and it works fantastic but what if you need to pull interface 7 out

38:57 to go somewhere else to another VLAN or to do a layer three then you have to

39:03 switch that the next interface range down below uh shows a range where we put

39:09 the members in individually into the range and then add that entire range to

39:14 unit zero family ethernet switching this way it helps us if we know we might ever

39:20 switch those up a little bit or reconfigure them to change those into a

39:26 different uh either VLAN or a different protocol

39:32 so once we have those we want to verify our status so we do a show interface terse we see our interface six seven and

39:39 eight there and they're up and we see the protocol is ethernet switching Now

39:45 by default we're going to go into basically a default VLAN for this since

39:51 we didn't specify one and that way if we all the interfaces with just ethernet

39:57 switching on them can all communicate as a switch together uh without describing an actual VLAN

40:06 we can do show interface extensive we can see that we have a little bit more

40:11 information here we see all the different protocols that might be running on that interface we see the the

40:18 the flags the costs the hold times so you can just see a bunch of information

40:23 about that interface now with the switching we're going to

40:30 have those tables right we need those layer two tables and so to look at those tables we're going to use the command

40:35 show ethernet switching table and show ethernet switching table is going to

40:40 bring up all of our interfaces here that are attached to our device and that that

40:47 have that it's learned so here we see user a b and c and we see those Mac addresses now inside of our table and

40:55 the interface that those hosts are attached to so that now we know when to communicate when a when a packet comes

41:00 into a certain layer to address we know which interface to send that out

41:07 once we have these tables we need to be able to work with them a little bit so one of the things we might do is we

41:12 might clear up those uh entries so it could relearn them or to get rid of one

41:19 that maybe gets stuck so here we just have a show ethernet switching table we

41:24 clear it out and then we run the command again and it's already learned two in that time it took to to get there but we

41:32 have we cleared those out and it's starting to learn those uh interfaces again

41:39 so we have a little switching configuration demo to show you now in our switch configuration demo we're

41:46 going to break it into two parts the first Parts relatively simple we're going to set up a few interfaces to pass

41:53 traffic and the main goal is to is to show you different ways to configure

41:58 Layer Two information in junos so we'll give you some different mechanisms for

42:04 Saving Time by configuring multiple interfaces with a few commands

42:11 then we'll take you into a full configuration mode where we look at vlans and access ports and trunk ports

42:19 and irbs so that we can route between the vlans

42:25 in the first part of our demo we're going to work on configuring interfaces we have client one and client two they

42:32 want to talk to each other they're in separate subnets ex2 is in a pure layer 2 mode so it

42:38 cannot route between subnets so client one will have to send it up to ex1 to be

42:44 able to forward back to down to client number two so we're going to focus on ex2 because

42:51 since it's in layer 2 mode we have three interfaces we have to configure because we need to have

42:58 untagged traffic so we'll configure those up so ge001 two and three so let's look at

43:06 our interfaces we only have our me we don't have any of the ge's configured

43:12 let's go to ex1 and do a ping 172 a 23

43:17 12.8 from our routing instance client one

43:23 and it fails so it doesn't work so let's configure some interfaces

43:30 so let's give you the long way this is the long way to do it in the

43:36 first place we're going to do set interfaces ge001 family ethernet switching

43:45 and at this point I don't have to type in anything more because the default value is the access mode and the default

43:55 VLAN is part of the default configuration when you use ethernet switching

44:00 but to rapidly try to do more we can just up Arrow hit hit up Arrow go back

44:07 and change the the numbers and so we're just up arrowing and

44:13 backspacing to get to there we go ahead and come out our work now when I commit my work

44:19 and I go over to ex1 and I do the pings on from client one

44:25 we know that configuration is sufficient to get connectivity we can do a run show vlans we can see

44:33 that our default VLAN which is tag number one is active on those three

44:38 interfaces so let's go ahead and delete that configuration and we're and instead of

44:46 doing it three different times we're going to do a wild card delete

44:52 this will let me delete multiple instances of something using Regis regex

45:00 we'll delete interfaces ge00123 and we hit enter it lists the interfaces

45:09 that are going to go and we say yes we want to delete those and we're going to do a commit

45:14 now we once we do that the Ping will end and there they go they stopped

45:22 so so what's another way we can configure this

45:28 so going to ex2 we're going to use the interface range

45:35 command set interfaces interface range we'll give it a name of L2 interfaces

45:42 remember at member and there's also a member range so at member you type in

45:50 individual members and member range you'd add a range of members you can mix

45:56 and match these with inside of the interface range so here we're going to

46:01 do a member range but we'll do ge-0

46:07 or or zero zero one two to ge003

46:14 once we have that range configured now we need to add those interfaces to the

46:21 ethernet switching family so we do unit zero family ethernet switching family interface mode access

46:29 vlans members default now remember that's the default setting we wouldn't

46:34 need to do that so let's look at the interface configuration that's that's all we got the individual

46:42 interfaces will not show up you'll just see the one range but when we do a commit

46:49 we can come back and see if the ping start back up and

46:54 there they go so their pings are working again the same way so that is an alternative way to

47:01 configure it so let's go ahead and delete those interface range

47:11 so we'll go ahead and commit it the pings should stop again now so let's

47:17 go back and check to make sure the Ping stop all right so they stopped again

47:22 so let's go another way to configure that we're going to use that wild card command again

47:28 so wild card so now you can say Wild Card range

47:35 set interfaces g00 and then we'll use regex on capability

47:44 we have and then

47:49 we put unit zero family ethernet switching interface mode access

47:58 and um vlans members

48:04 default commit that

48:09 and once again our ping should start back up

48:15 there they go so we have multiple ways to configure layer 2 information quickly on junos

48:26 in this part of our demo we've got a few more steps but we're going to configure

48:32 a situation that is more common in the workplace so in this case we're going to be using vlans

48:39 and we have two clients that are connected to our switch client one is part of is part of VLAN number 11 and

48:46 client 2 is part of VLAN number 12. we're gonna have to consider their access ports correctly in the right

48:52 vlans and those vlans will need to be trunked and we have a trunk Port between ex1 and

48:59 2 which is ge001 and we'll have to configure both sides of that trunk port

49:06 and then they're going to be connected to servers which are already configured up here on ex1 and so the vlans have

49:13 already been built on ex1 but to build a route between them we're going to create IRB interfaces and make sure that we can

49:21 reach between the two subnets so let's get started we're going to start on ex2

49:29 and on the X2 we're first going to configure the vlans so do show vlans we

49:34 have our default VLAN so let's do set vlans v11 VLAN ID 11.

49:44 and then set vlans V12 VLAN ID 12.

49:50 show vlans shows us our vlans next we're going to configure our

49:57 interface we'll start with ge001 we'll go in order

50:03 and so here on g001 we're going to have a trunk interface so family ethernet

50:09 switching interface mode trunk and it has two vlans we're going to add

50:16 VLAN members where there's two of them v11 and V12

50:23 now our next interface going to be ge002

50:29 so we'll go there ge002 family ethernet switching enter phase mode access

50:37 because it's an access port but our VLAN members will be just one which will be

50:43 VLAN 11. and then we're going to go to our third interface

50:49 gez ge003 family ethernet switching interface mode

50:57 access members VLAN members

51:03 V12 so do a show interfaces we'll take a

51:08 look at those they look like we have our trunk and our access ports created

51:15 we'll go ahead and commit check on that to make sure it looked to see if it works okay

51:22 we'll go ahead and now commit it and that should be what we need to do on ex2

51:29 we're going to jump to ex1 now on ex1 the vlans should already exist because

51:36 we added those for the servers and they are there but our trunk Port is

51:43 not configured so let's look at interfaces and we don't have that interface so let's do set interfaces

51:49 g001 family ethernet switching interface mode

51:56 trunk and VLAN members

52:01 is v11 and v12.

52:08 okay now we need to configure our IRB interfaces and these are special

52:14 interfaces used for for inner VLAN routing they're called integrated

52:20 routing and bridging interfaces so we'll configure those with set interface

52:26 irb.11 that's our logical unit we're going to match that with our VLAN

52:31 just for troubleshooting and so family inet address 72 23

52:40 11.124 and set interfaces are B12 family inet address 172 2312.124

52:51 and now these IRB interfaces don't do anything but we need to bind them to the

52:57 vlans so we need to configure those inside the vlans so set vlans v11 and

53:05 we're doing L3 interface a layer 3 interface IRB 11. and the same on 12

53:12 said vlans V12 L3 interface IRB Dot 12.

53:19 now to verify the work we can do our shows but we can do a show Pipe compare

53:26 and look at the differences between the the active configure configuration and

53:32 what's between the candidate configuration so we've only added stuff so you see it's all pluses on this side there so

53:40 we'll do a commit check just to make sure it's done properly and we're good so we'll go ahead and do

53:47 our commit

53:55 now let's make sure our client can reach the Gateway

54:01 so run ping 172 that

54:08 23.11.1 from our routing instance client one and it can see our default gateway

54:17 or let's see if we can get to the server and we can get to our server

54:22 so now let's try client two so we'll change to the other routing instance and get to their Gateway and they can and

54:30 then we'll check to see if they can get to their server and see oh and they can get to their

54:36 server so our vlans are working but can client one get to client two so we're gonna try

54:44 and get over there and yes we can so so let's try client one can see the

54:51 client two's server and then it can do that also so everything's working as it should be

54:57 and that completes our demo our next topic is Port security

55:04 security is a concern for every Network that's out there we're trying to keep

55:10 hackers off of our Network we're trying to keep uh threats away from our

55:15 resources and what's even worse is if those attacks come from a trusted Source

55:23 inside of our networks well these trusted sources they might be trying to

55:29 break in or they might just not know that they're helping some somebody break in and so we need to be as Network

55:37 administrators aware of these features and be able to secure the ports on these

55:44 switches now many businesses have worked very hard to string ethernet cable ports

55:50 to almost everywhere in their buildings so that you can easily attach net

55:55 computers and resources to the network to function

56:01 and when these K when these ports are open and you can plug anything into them then they can

56:08 become a problem so Juniper with their Juno switching has a lot of Port

56:15 security features that can be used to help secure your network and we're going

56:21 to go through and talk about some of those now

56:26 so every switch from juniper comes with a default configuration and on that

56:32 default configuration all the interfaces are put into a ethernet switching family

56:38 uh setup and so they joined the default VLAN so right from the get-go you can

56:45 plug in and be part of that VLAN now that's great if you're trying to get a

56:50 network to function but if you keep the default settings then this that's not

56:56 very secure as a as a switch so uh what we want to do is we want to

57:03 make sure that we can go in and configure these to help secure up some

57:08 of those options that we have so let's think about this for a second

57:15 so here we have a user and this user sitting at his desk and for whatever

57:22 reason the user is like look I need another computer I want to bring my my laptop and hook in next to my desktop or

57:30 maybe I want to hook in a printer or other asundry devices that are out there

57:35 and so he brings in a switch and plugs that switch in well and there might not be any problems

57:44 with that but one thing you do know is that the IT department does not know

57:49 about this switch and that's why we call it a rogue switch it's not part of their inventory they're not looking for it and

57:56 what happens if this switch is running spanning tree and it's joins your

58:01 spanning tree and it becomes the root bridge and then all of a sudden all your

58:07 traffic flows are changed and either detrimentally or completely and and so

58:15 now maybe your network doesn't even function because of this Rogue switch a lot of people are now putting in these

58:20 Rogue wireless devices right so they can plug in and then they can get to their

58:26 uh their their tablets or other devices around their work area and they want to

58:33 make their own little Wireless domain so any way you look at it there's

58:38 different things that could happen if people bring in their own devices and you can't stop this from happening uh at

58:47 most levels I mean you can you can have education and teach them not to do these things but at some point somebody might

58:54 do it so you need to learn how to program and configure the switch so that

59:00 if they do these things that they can either you can know about them or you

59:05 stop them from making these changes to your network and then also the last

59:11 scenario here we got user C and he's just spoofing or flooding applications and trying to bring down your network

59:17 he's an actual malicious person the first two scenarios probably are not malicious people they just don't

59:24 understand what they could be doing to your network by introducing equipment

59:30 that was not issued from the company one of the ways we can stop this is by

59:36 using what we call Mac limiting Mac limiting will protect your network by

59:42 allowing only uh so many Mac addresses to be off of each port and by default

59:50 with that default config there is no limiting on the number of Macs on a port

59:56 so we could have hundreds of Macs come through an interface but if you know

1:00:02 that one interface is going out to a single computer you could set the Mac

1:00:07 limiting on that to one and so if we have more than one then we can have some

1:00:13 options that we can do right we can we can just alert the administration that

1:00:19 you know put it in the logs and say hey look there's there's a glitch here or we

1:00:24 can just ignore the packets coming from the second Mac address or we can

1:00:30 actually shut the interface down so there there's a lot of different things we can do in that scenario but here

1:00:38 we've made a way so if somebody does bring in a switch and adds multiple devices at least the admin team can know

1:00:46 about that and can work to figure out how to rectify that uh here we just have

1:00:52 an example of that right we see we have two different Mac users come down and so

1:00:58 if we only have it where we can have one Mac address then we'll perform some

1:01:04 action on that so the first thing we can do is put Mac

1:01:09 address limiting on and so here we can say hey each interface we can go in and

1:01:16 configure how many Mac addresses can be learned through that port and so here we

1:01:21 see in our list that we have ge006 can learn two Mac addresses and the other

1:01:27 ones can only learn one Mac address and that way on ge006 if you'll see in the

1:01:33 diagram there's a phone and a computer and so there's two different devices there that need to have their Mac

1:01:40 addresses be listened to just makes it easy for you to control how many devices

1:01:46 are on your network and which devices those are

1:01:51 we can also put a loud Mac addresses and so we can actually go in and configure

1:01:57 on the switch interface hey look the this Mac address can talk to me and no

1:02:02 other Mac addresses can talk to me so now that computer you'd have to find the

1:02:07 MAC address off the interface and configure that into the switch and then that is the only computer if it gets

1:02:15 sent traffic through will be able to communicate through to the network so we do that on an interface by

1:02:22 interface level to configure that we can also set up a Mac move limit a

1:02:29 Mac move limit is how many times a second can a Mac move through to a different interface now a lot of times

1:02:37 we're going to actually set this up to create uh protections against loops and

1:02:43 other attacks that might be trying to move a MAC address for an attack so

1:02:49 that's what we want to do here with this Mac move limit as we'll set up and say hey look these Mac addresses should stay

1:02:56 on these interfaces and if they move you know we can't they're not going to move too fast and that way we can shut down

1:03:04 attacks and layer 2 spoofing so when we have set up these Mac

1:03:13 limiting features there's some actions that we can do and so one of them is

1:03:19 none right we can just say whatever and we'll just keep doing whatever we want to do which is basically the default so

1:03:26 that might not be what you want to do log will allow things to work but it

1:03:32 will let you know that something happened right now if you've set a Max limit of one you only get a Mac limit of

1:03:39 one but if you have two then it's going to log that error into the the logs that

1:03:44 hopefully you'll be able to see and that'll bubble up to the IT department to be able to find out what's going

1:03:51 wrong now we have a few more we have a drop which just drops the packets from the

1:03:58 second Mac address right so if we have a Mac limit of one the second one comes on

1:04:03 we're just going to drop all those packets we also have a drop in log so we'll drop those packets and log that

1:04:10 we're dropping those packets and then we have the last one is shutdown we'll just

1:04:15 shut down that interface now once we shut down that interface now nothing

1:04:20 goes through that interface so this is a really good way if you want the people

1:04:26 to um kind of self-police themselves or turn themselves in because once they

1:04:32 hook up a second machine maybe off of another a rogue switch their interface goes down and then they're going to call

1:04:38 it and say hey the machine doesn't work and as you look into it you'll find that this interface was shut down then you

1:04:44 can have a discussion with them about what's going on and and maybe help teach them about that switch

1:04:50 so these are the actions that we can have as we go through to create this Mac

1:04:56 limiting Now by default once these interfaces get

1:05:02 shut down they stay shut down and you're gonna have to manually go and

1:05:09 clear that interface and we use this command here clear ethernet switching recovery timeout and if you did that

1:05:16 command and hit enter right there you're going to clear all the interfaces you can also just put an interface name on

1:05:22 the end of there and clear just the one interface so you get to pick what you want to do

1:05:28 there but you can also set a recovery time on this device that says hey look

1:05:33 we only want to shut down for a minute or two minutes and you can set a time so

1:05:39 that um it'll pop back up and try to start working again and see maybe they pulled

1:05:46 the other device off the network because once they hooked it up it stopped working they pulled the device off and

1:05:52 and now you can automatically set so it'll start working again so you don't have to go run this command

1:05:58 all the time so how do we do this so here's we're going to show you how to configure uh

1:06:04 these accepting a certain Mac address so this again is on the interface that we're going to put this on and you see

1:06:11 here we put um under the interface under the unit 0 except source Mac and we have a couple

1:06:19 Mac addresses here and so now those are the only Mac addresses that are going to be allowed on interface six and as they

1:06:27 come in so this is a great way to add these in

1:06:32 there and to be able to make sure that um you have the the machines talking on

1:06:39 the ports that you want so underneath the switching options and

1:06:44 we're switching over to switching options here's where we're going to configure up all the other types of Mac

1:06:50 limiting and so here we're going to say look we want two uh different Max there and if

1:06:56 we have more than two Macs uh Mac addresses what are we going to do we're going to log drop or shut down or drop

1:07:04 drop and log so we show all the different pieces there now we can set

1:07:10 that up on underneath an interface or if you go down to the vlans section of the

1:07:17 configuration we can add this to the VLAN and say hey look any interface that comes into this VLAN we only want to

1:07:24 have three Mac addresses as the configuration shows on the screen so this is an easy way to just say hey

1:07:32 look we we know that this VLAN we need uh maybe a computer and a phone and

1:07:40 maybe a printer off of each link and so we know we'll never have more than three devices out there no matter what happens

1:07:48 and so then it just gets pushed to any interface that gets added to that VLAN

1:07:55 we can also configure up the Mac move and here we have underneath our VLAN we

1:08:01 can do our Mac move limit of one so every one If It Moves more than one time

1:08:07 per second um we are going to say hey there's something wrong here and

1:08:13 we're going to shut down that interface again this helps with a flooding or or a

1:08:19 loop that gets created in our networks and and this is a great thing to have on your networks uh if you do ever create a

1:08:26 loop within your network so some of the commands we have for

1:08:31 monitoring the Mac limiting here we use the show log messages and we can see the

1:08:37 logs that get generated here so here we see that we had the the Mac limit reached on an interface and that we

1:08:45 blocked that because the Mac limit was exceeded and so we started blocking that

1:08:50 you can also do a show ethernet switching interface ge009 or whatever interface that you're

1:08:57 on and you can see what the Mac limit is and you can see that the action was

1:09:03 dropped and the limit was hit and that's what the ad and the LH stands for the limit the Mac limit was hit and that the

1:09:11 action was we dropped the uh packets from that interface

1:09:17 persistent Mac learning is a configuration option that we can set and

1:09:22 when we have this set we will keep the Mac addresses that we've learned off of an interface

1:09:29 in the Mac table and so what this does for us is if we

1:09:35 combine this with Mac limiting then we will learn the Mac addresses

1:09:42 that are out there and even if somebody unplugs a port plugs a new Port back in or reboots the device the switch then we

1:09:51 will retain those Mac addresses that were on that divide on that interface and if we remember those inner those Mac

1:09:58 addresses on that interface and a new one shows up and we have mac limiting

1:10:04 enabled also then we have no space to learn a new Mac address and so this can

1:10:11 be a security feature for us that once we have it set up somebody can't come unplug a port and plug a new computer

1:10:17 into that port and try to break through that saying oh look there's only one Mac

1:10:23 address we can keep the old Mac address that's with that device on that interface

1:10:29 there are some guidelines to to work with on this and the interface must be a

1:10:36 access port all right so we can't run it on a trunk port uh it cannot be a member of redundant

1:10:42 trunk group The persistent Mac learning does not work if the interface is using 802.1x Authentication

1:10:50 and the interface must be enabled to learn Mac addresses so we can we have to

1:10:56 be able to learn them but once we learn them we'll maintain them even through reboots on that switch

1:11:03 so how do we configure that we can figure that under the switch options with interface and put persistent Dash

1:11:11 learning on that in that hierarchy and that will turn that interface into

1:11:17 remember where the Mac addresses even through reboots or interface going down

1:11:22 and back up once we need to monitor that we can do a

1:11:28 show ethernet switch table and we see that we have our Mac addresses on the different interfaces but here we'll see

1:11:35 we have a p for persistent for that Mac address instead of just a dynamic one

1:11:41 that we learned and so here we can have that Mac address that 74 colon 86 even

1:11:49 if we reboot the machine it will maintain that MAC address on that interface and we but we did learn that

1:11:56 to begin with so again this can be a great security method to use on our ports

1:12:03 our next Port security option is for DHCP so let's just kind of go over how

1:12:10 DHCP works right it's a dynamic host control protocol and what this does is it allows a

1:12:16 machine to ask onto the network the local Lan uh hey I need an IP address

1:12:22 and I need Network information so that I can operate on this network and as you

1:12:27 can see here it'll send out a discover packet the server will see it send back an offer packet a request packet gets

1:12:36 sent back to the server and then the the actual DHCP acknowledgment gets sent

1:12:41 back and then the the client now has an IP address a subnet mask and other basic

1:12:49 Network information so that it can work on that Network

1:12:55 there are some vulnerabilities that we have with DHCP and one of those is that those packets

1:13:03 are all broadcast out which means they're flooded to every port on the switch so when the switch receives one

1:13:10 of those packets it takes it and pushes it out every port now usually you only

1:13:16 have a one or two DHCP servers on your network that you are controlling but

1:13:24 um any DHCP server on that Network could get it and be able to respond and so

1:13:34 there has been many instances where people will go and bring in their own little wireless device or a little

1:13:40 switch or some device to be able to expand their little Network in their cubicle

1:13:45 and then that what happens is that then that machine starts to respond to DHCP

1:13:52 requests before you the main machine does and you can start to bring machines

1:13:58 down and make them not work on the network DHCP snooping is a way to combat some of

1:14:04 these vulnerabilities the DHCP has and what we're going to do is we're going to inspect that packet as it goes through

1:14:11 the switch and we're going to watch for all of those packets that are on untrusted

1:14:17 ports and what we mean by an untrusted port is all of our access ports are then going

1:14:25 to be untrusted and trunk ports will be trusted and then we can go in and configure and

1:14:32 a trusted port for our server and so now when a broadcast comes into

1:14:38 the switch we take that and we're only going to deliver the the packet instead

1:14:45 of broadcasting it out everywhere we're only going to send it down to the trusted access ports that we have and

1:14:51 our trusted trunk ports because the trunk ports are trusted because we need to get back to wherever uh the server's

1:14:58 at and then once we get down to the access port link then we want to send it out to the server and we don't want to

1:15:04 send that packet to anybody else so all the other access interfaces would be considered untrusted at that point and

1:15:12 then we're going to maintain a database of all those associations of IP addresses and Mac addresses and the

1:15:18 interfaces they're attached to so this is that snooping process so the

1:15:25 DHCP client is going to send over its DHCP discover packet and then the switch

1:15:32 is going to see that it's going to keep track of that information saying hey this Mac address from this machine is

1:15:39 sending a response the switch will then sport it out to the trusted ports which

1:15:45 should go out to your DHCP server this the the DHCP server then is going

1:15:52 to go ahead and send back a packet um with the offer again we'll Snoop that

1:15:58 we'll be able to grab all that information in there and be able to now say hey look this MAC address on this

1:16:05 interface is going to be assigned to this IP address because it looks inside the packet that's coming back from the

1:16:11 server and then we so now we know where the IP address and Mac address and the

1:16:18 interface for all the machines are at in our Network

1:16:23 so this is how we configure this it gets configured under our vlans and we're

1:16:29 going to go under our forwarding Options under our VLAN and put a DHCP security uh group in there we'll name that group

1:16:37 and then we're going to say um which interfaces are trusted inside

1:16:43 of there and so what why we do that is that's where your DHCP servers are going

1:16:48 to be plugged into is on that trusted interface there and then you also have

1:16:54 your a group of untrusted interfaces and then we can add all the interfaces into

1:16:59 that all the rest of them into there and this again lets us not send that

1:17:05 broadcast packet out every interface but only the trusted interfaces once we have this running we can go

1:17:12 ahead and run a command called show DHCP security binding and we see that we have

1:17:18 our IP addresses our Mac addresses we see which VLAN they're attached to and we see the interface that they're

1:17:25 attached to and so we keep track of this and so now we we know where all the IP

1:17:31 addresses are the Mac addresses and we're stopping these Rogue DHCP servers

1:17:38 from answering uh if our networks need it so if I bring in a DHCP device and

1:17:45 plug into my network I'm never going to receive those uh broadcast packets so I

1:17:52 can never get in and mess up and break the network with my DHCP server that I bring in on my own

1:18:00 there's times when you want to go ahead and clear this table so you can do a

1:18:07 clear DHCP security binding you can clear for all of them right or you can

1:18:13 clear just for a specific VLAN or you can clear for a specific interface or

1:18:18 you can clear the IP address so however you might need to clear that database

1:18:24 out to do troubleshooting or to try to rebind another IP address whatever it

1:18:30 might need to be there we can also add static entries so if you

1:18:36 know the IP address you're going to get to one of the machines we can basically

1:18:42 go through and set up static entries so that this IP and this Mac have to be attached to this interface

1:18:48 and you can see we do the run show DHCP security binding down below and it says static and the only way to get that

1:18:55 static piece back out of the database is by removing the configuration and doing

1:19:00 a commit so this has been DHCP snooping

1:19:06 our next agenda item is high availability features within our switching platforms

1:19:12 what is high availability High availability is having operational continuity from

1:19:21 your users to the resource that they need to get to and over a specific

1:19:26 period of time so usually we go on the opposite side of that and say look we're

1:19:33 going to give you three nines or five nines now three nines gives you nine

1:19:38 hours of downtime a year where five nines gives you five and a half minutes

1:19:44 per year so it's quite a bit of difference in the downtime between three and five nines over the course of a year

1:19:52 but this is the how much you will tolerate your systems not being available is is those numbers so if

1:20:01 you're on that side if you gotta you gotta keep networks up and running well Juniper Networks has some features in

1:20:07 the switching devices that we'll talk about here the high availability features on our switching devices are

1:20:15 link aggregation groups or lags we have redundant trunk groups or rtgs graceful

1:20:21 routing engine switch over or g-res or non-stop active routing NSR and non-stop

1:20:28 bridging NSB now each one of our devices runs these maybe just a little bit differently or

1:20:36 maybe not at all and so you need to check each device's uh features to see

1:20:41 which ones of these features that they support so lags what is a lag a lag combines

1:20:50 multiple physical ethernet links into a single interface

1:20:56 and those individual links are called member links and so we'd have a lag

1:21:01 interface with one link two links Three Links you're usually going to have more

1:21:07 than one and within those links we can then round

1:21:13 robin traffic across those two links to send traffic across both of those

1:21:19 when we have these lags we get increased bandwidth right so now we don't have

1:21:25 just one gig link we have two gig links and so we can fill both of those up with traffic if we have three four five we

1:21:33 can have multiple gigs of traffic going across a single interface uh according

1:21:39 to the switch but they're being pushed across different links with the inside of the physical layer there

1:21:47 this gives us more efficiency we're not just having another link there in case

1:21:52 something goes down it's actually being used at the time and then of course we get that redundancy so if we do lose a

1:21:59 link then hopefully we still have one of the other ones running and we're still being able to send traffic across that

1:22:06 interface there are some requirements for our lags to work and some of those are we need to

1:22:13 have a full duplex and the link speed must match so we can't have a full

1:22:19 duplex and a half duplex link and we can't do a gig in a 10 gig link they all have to be the same type of interfaces

1:22:27 we can have up to 16 member links per lag that does change per device but

1:22:33 that's pretty standard is 16 member links per lag member links do not need

1:22:38 to be contiguous right so we could pull them off of different uh FPC cards so

1:22:44 that if we lose an FPC our lag is still running helps us have a little bit more

1:22:50 redundancy that way how do we process the traffic to go across here so any routing engine

1:22:57 generated traffic that needs to go across is always sent across the lowest member link ID

1:23:04 so IP traffic is going to use some type of a hashing algorithm and that hashing

1:23:11 algorithm is going to decide based upon your source and destination ports and

1:23:16 and addresses which interface it's going to take across there so that's how we get

1:23:22 traffic to flow across different links and non-ip traffic hashes using source

1:23:29 and destination Mac to go across the links and to spread that across

1:23:37 there's a protocol called link aggregation control protocol lacp and

1:23:42 lacp is used to Monitor and control the links to push the traffic across and

1:23:49 just make sure everything stays up and working you always have to have one active side

1:23:55 so when we configure these devices we need to configure one side for active and the other side for Passive if you

1:24:02 configure both sides for active they'll negotiate and one side will step down

1:24:07 and not be active but if you configure both sides for Passive your lacp won't

1:24:14 function and the link will never come up so you need to make sure you at least put one side in as uh active when you

1:24:23 can figure up your lags so configuring up our lag here you see

1:24:29 we went into the chassis hierarchy and we just ran the command to show all the

1:24:35 AE interfaces really quick and you see that we don't have any so then under chassis we're said set

1:24:41 aggregated devices ethernet device count one that's if you want a single lag if

1:24:47 you wanted more than one lag you'd add that up to that number right two three four however many lags you want to

1:24:53 configure and then we're going to go ahead and commit that once we commit that we run that shoot run show interface Church

1:24:59 command again we see that we have an ae0 interface so that just created an

1:25:06 interface because we added that into the chassis and now we can go ahead and configure that AE zero interface

1:25:15 so now once we have that ae0 interface configured we can go in and add the

1:25:21 member links to it so we can add Our member link here we add interfaces 11 and or excuse me 12 and 13 to the lag

1:25:29 and we're going to run the lacp protocol and this is going to be the active side

1:25:35 and so we then we can also add it to a VLAN and so down at the bottom after we do

1:25:41 our commit you see that we can look at our interface there and because we put

1:25:47 that a0 we're going to match any line that has anything to do with a0 so we get all of our member interfaces and

1:25:54 then The Logical interface that we created to send traffic across

1:26:01 so when we want to monitor these we have the show interface command that we just showed again and that shows us

1:26:09 um that all the interfaces are up and running and then we can also put an extensive tag on there and when we put

1:26:16 that extensive tag you can see the actual lacp traffic going across to make

1:26:21 sure that it's working and functioning properly

1:26:26 given the example outputs here can you guess what might be causing the ae0 to

1:26:31 remain in a down state

1:26:37 right if you look down below we don't have any lacp packets being received

1:26:43 from there so we probably need to go to the other device and configure lacp on

1:26:49 that lag interface that we tied to redundant trunk groups is the next option we can have to provide High

1:26:57 availability and in this we see that what redundant trunk groups does is it

1:27:03 helps us replace our spanning tree protocol down on our access switch as

1:27:09 long as we have two interfaces that go up to aggregation layer switches we can

1:27:14 turn RTG on and replace our STP protocol

1:27:19 how does it work RTG what it does is we're going to Define two different links we're going

1:27:26 to define a primary link and a secondary link and when we Define this the traffic will

1:27:34 flow across the primary link the secondary link only sends control protocols and things back and forth but

1:27:42 doesn't send any data back and forth on it unless the primary link goes down if

1:27:47 the primary link goes down then we will move all the traffic over to the secondary link when until the primary

1:27:54 link becomes active again when we configure RTG there's a few

1:27:59 things we need to keep track of RTG and and spanning tree are mutually exclusive

1:28:05 meaning we can configure both of those on the same interface or we'll get a commit error

1:28:11 so and if we received a spanning tree bpdus from the aggregation layer we'll

1:28:19 go ahead and just throw those away this is all programmed down on the access

1:28:25 layer switch and but you'll want to keep your spanning tree protocol up on your

1:28:31 aggregation layer programmed in there if you have any redundant links so that you will not have any type of a layer 2 loop

1:28:39 at the aggregation layer all right so let's see how we would configure that here we have a topology

1:28:46 we have switch three and we want to configure RTG on switch 3 so that uh

1:28:54 only one of those interfaces either ae0 or ge0010 will pass traffic at one time

1:29:04 so we want to make sure that the AE 0.0

1:29:09 interface is primary whenever it is operational

1:29:14 so let's take a look at that so here you can see inside configuring

1:29:20 our RTG that we're going to do that under the switch options and we have a

1:29:26 set redundant trunk group group and give it a name rtg1 and then we can put an

1:29:31 interface in there we're going to actually put two interfaces into that group that we just configured and if we

1:29:40 want one of them to be primary over the other one we will add the primary tag if

1:29:46 we do not add the primary tag the highest numbered interface will become

1:29:51 the primary interface by default once we have that configured we can go

1:29:59 in and take a look at that using a show redundant trunk group and we see we have

1:30:05 our one group The RTG one group and we have two interfaces in that group we see

1:30:10 both interfaces are up but we see that the ae0 is the primary and active

1:30:17 interface we can see when the last time that they switched over and it was it's

1:30:23 in this case it was never and we can see how many times it's switched over

1:30:29 so we get a little bit of information there so we can see that we fulfilled what we wanted to with our redundant

1:30:36 trunk Group by that configuration the next high availability option is

1:30:42 graceful routing engine switch over what this does is this preserves the

1:30:48 forwarding plane state in the event that a routing engine fails and we need to

1:30:54 move from the main routing engine to the backup routing engine when this happens

1:31:00 the packets that are going through the switch will continue to go through the

1:31:06 switch because the interfaces did not have to to shut down and restart as they

1:31:12 would if we did not run this option on the switch so that we basically can maintain that

1:31:19 uh the forwarding Plane State of the switches when this switch over

1:31:26 from the main routing engine to the backup routing engine happen

1:31:33 here in a virtual chassis is the scenario and in this virtual chassis scenario we have some keep alive that

1:31:41 are being sent between the switches and then once we're watching those and the

1:31:49 res are synchronized the the keepa lives are being exchanged if the backup

1:31:54 routing engine does not receive a keep a light from the master routing engine after about two seconds it's going to

1:32:03 determine that the master routing engine has gone down and it is going to initiate takeover and bring the routing

1:32:12 over to the backup routing engine now the PFE remember is going to

1:32:19 seamlessly disconnect from the one routing engine and attach to the next routing engine so that all the interfaces do not need

1:32:27 to bounce they don't need to go down and come back up to reattach to the new routing engine

1:32:32 so once those two synchronize then all the state information can be uh replaced

1:32:39 now this does not keep any of the control plane uh information in place

1:32:46 and you will have to re-initiate all your routing protocols and things like

1:32:53 that so your peer devices will know that it went down but only at a layer three level the layer 2 level it will not know

1:33:00 it went down with graceful routing engine switch over how do we configure that we can

1:33:06 configure that under the chassis if we just say set redundancy graceful switch over we go ahead and commit that and now

1:33:14 it is running and we can preserve that forwarding plane data

1:33:20 we also want to be able to monitor it and monitoring it is a little interesting because we cannot monitor it

1:33:27 from the master routing engine we have to monitor it from the backup routing

1:33:32 engine and so as we go and switch over to the backup switch here in in our

1:33:39 option here it says we do show system switchover and we can see that it's it's

1:33:44 turned on it's ready everything is synchronized and we're ready for a failure so that we could switch over

1:33:51 and then down below that we just do a quick show on the master routing engine

1:33:56 and that option is not even there uh to run so we can't do show system

1:34:01 switchover because it's not even an option on the device

1:34:08 the next option is non-stop active routing and what non-stop active routing

1:34:14 does is it's going to preserve your layer 3 routing tables between the two

1:34:20 devices it'll synchronize those tables up so that if we switch from one routing

1:34:26 engine to the next that we don't have to alert the piers that we went down and

1:34:31 try to resync all the routes we just already have all those routes in the routing table we must have the graceful

1:34:39 routing engine switch over turned on to run this option and so basically we're

1:34:45 going to just preserve our layer 3 routing information

1:34:52 if we want to configure this it's going to be under routing options and we just do set non-stop routing and then once we

1:35:00 do a show we can go ahead and commit that in this option we showed that we do

1:35:07 not have graceful switch over enabled on this configuration and so it gives us an

1:35:13 error after we put that in there so we need to make sure we have both of those turned on

1:35:20 you also must synchronize the configuration between the res right so we need to do Under the system hierarchy

1:35:27 set commit synchronize so every time we commit we will synchronize the

1:35:32 configurations between the active and the backup routing engines so that they

1:35:38 are ready to go when there is a problem we want to make sure that it's running

1:35:45 right we can go ahead and do a show task replication and we're going to see that

1:35:51 the protocols we got ospf and bgp shown there and that those are

1:35:56 synchronizations are complete and so if we did fell over those two protocols

1:36:02 would not have to reach out and and re-establish an adjacency because it

1:36:08 would already be handled by the backup routing engine

1:36:15 non-stop bridging is the same thing except for layer 2 devices so we have

1:36:21 these Layer Two switching tables and so non-stop bridging will maintain those

1:36:27 tables on the uh backup routing engine and synchronize those across as they're

1:36:34 learned and so it again it does a lot of the same things that the non-stop routing does but now we want to preserve

1:36:41 the layer 2 information again we're going to need to have the graceful routing engine switch over enabled to be

1:36:48 able to run this also we can figure this under the protocols

1:36:54 layer 2 control set non-stop bridging and we go ahead and commit that to set

1:37:01 up a seamless failover between routing engines you'd want to turn on your graceful routing

1:37:07 engine switch over your non-stop routing and your non-stop bridging so that we'd

1:37:14 have a seamless failover from one routing engine to another on our devices

1:37:22 our next agenda item is ipfabrics

1:37:28 our Layer Two networks have been around quite a while now and they've served us

1:37:33 well but there are some limitations to them as we move forward with more

1:37:38 devices faster speeds and needing to use more of our resources

1:37:44 so our traditional Layer Two networks required to have a

1:37:50 loop prevention so we wanted to have more than one link set up so if we lose a link we could use another one as a

1:37:57 backup but that backup link could not be used it was actually blocked by a

1:38:03 protocol usually spanning tree so that we couldn't even use that one unless the first link went down

1:38:10 because of that as we scale and we add more and more interfaces we can only

1:38:15 have one that gets put in there so we can't really scale very well either and as the network gets bigger spanning

1:38:24 tree takes longer there's latency involved there's different sized hops to

1:38:29 different machines so we can't use equal cost multi-path

1:38:34 we can't use these device these these mechanisms that we have in these setups

1:38:41 this has mainly been for our data centers and our bigger networks but that

1:38:48 is being transitioned into our Enterprise our Enterprise networks need updating

1:38:54 also and the old designs have been around for a long time and we're going

1:39:00 to move those into a new design because of these same things speeds are

1:39:06 increasing uh

1:39:12 so the IP fabric that is the physical piece of our Network

1:39:18 is going to need to be flexible we want to be able to use multiple devices from

1:39:26 different vendors we want to have a highly scalable and we want it to all be

1:39:33 layer three and in this way we won't have any of those same problems we have with our layer 2 Fabrics

1:39:40 IP fabric infrastructure is all IP so there's no Layer Two there's no spanning

1:39:48 tree we basically get all of our links back we don't have to have the latency

1:39:53 for that there's no flooding for information they're going to use standard-based

1:39:59 protocols like ospf and bgp which allow for multi-vendor implementations so

1:40:07 you're not stuck with a single vendor if you go with an IP fabric

1:40:12 we when we design this every server should be two hops away from any other

1:40:18 server or a workstation should be two hops away from any other workstation in the entire network this way we can use

1:40:25 equal cost multi-path to help use more links throughout our Network

1:40:31 the network will just go ahead and it's going to scale linearly as the size

1:40:37 increases so as we add more devices we can just add more Leaf switches into our

1:40:45 Network and this was a method developed by Charles Kloss and these are called a

1:40:51 cloth fabric sometimes through these IP Fabrics so let's dive in a little bit more and

1:40:56 see how these kind of work so in this spine and leaf architecture each Leaf is

1:41:02 going to have a link to each spine and so if you have four spines each Leaf

1:41:08 will have four network connections to the spine network if you only have two

1:41:14 spines then each Leaf will only have two connections up to the spine

1:41:20 so this is going to create a resilient Network where everything has the same

1:41:26 number of hops or jumps so that the equal cost multi-path protocols will all

1:41:31 work there is no physical connectivity between any of the spines and there's no

1:41:37 physical connectivity between any of the leaves so the leaves hook only to the

1:41:43 spines so if the spines need to send control information to each other that

1:41:48 will all go down through one of the leaves and back up to the spine switches

1:41:54 traffic should be load shared over these because of the way the multiple paths work there's four distinct paths between

1:42:02 host a and host B now because of the way the spine architecture works and all

1:42:08 unicast packets are going to flow on that same path based upon a hashing algorithm because we want we don't want

1:42:16 one conversation or one flow to go across multiple links because our

1:42:21 packets can get out of order so we want to use so we have a hashing algorithm as

1:42:26 the packets come in the packets between one machine and another machine will all

1:42:32 flow across the same link thus creating a single path for that one

1:42:38 communication the best practices for an IP fabric is that all the spine nodes should be the

1:42:45 same type of router you don't want to mix and match different types of routers because you want them all to work at

1:42:51 about the same speed every leaf node then also needs to attach to each one of the spines

1:42:58 we want to use the same link speed so that the igps do not take different

1:43:03 links into different calculations and then we lose our equal cost multi-path

1:43:09 links and that same thing with ebgp egbhp does not look at the speed of the

1:43:15 link it does not take that into consideration so if you have one link that's a a hundred gig and you have

1:43:21 another link that that's a one gig link then you the ebgp does not understand

1:43:28 that and might send everything across the one gig link so we want to keep our link speeds the same from the leaf

1:43:35 switches up into the spines all the way across our Network

1:43:41 now that we have the underlay or the IP fabric created we need to move on to the

1:43:47 overlay we have had compute and storage be

1:43:52 virtualized for years now and it's just time to get the network to be

1:43:58 virtualized also so we can automate connections on and off of a network without worrying about bringing the

1:44:04 entire network down vxlan is one of those protocols that has

1:44:09 been created in the hopes that we can do just this it basically decouples the network from

1:44:16 the physical Hardware so that we can create vlans on the Fly and be able to

1:44:23 create what we call virtual tunnel endpoints V Taps for each of the vlans

1:44:28 it gets created to be able to communicate back and forth across the network but how does it know how to talk back

1:44:37 and forth across the network in the VLAN that it has we use a protocol called evpn

1:44:44 evpn uses a multi-protocol bgp to exchange data and that data that gets

1:44:53 exchanged are Mac addresses so if we see here we have host one and it is attached

1:44:59 to Leaf one and then on the right hand side we have host 2 and is it attached to Leaf six

1:45:06 when Leaf one learns the MAC address of host 1 it will transfer that through

1:45:12 evpn over to Leaf 6 and vice versa leave

1:45:17 six will take the MAC address learn from host 2 and advertise it out to Leaf one

1:45:24 and now those two machines can talk to each other on the same layer 2 network using Mac addresses but across a layer 3

1:45:34 Network here in a couple slides we'll have more of a detailed explanation of

1:45:39 how that works so evpn it's a control plane protocol

1:45:45 right it's based on bgp it's highly scalable you can apply policies to it so

1:45:51 it's very you can manipulate it and change it however you need it to work we

1:45:57 do all active forwarding so we can forward across multiple paths using

1:46:02 multi-path forwarding we have our control plane Mac learning

1:46:08 uh it reduces unknown unicast flooding and reduces art flooding because we

1:46:14 don't need to ARP all that stuff across because we've learned it we're going to put it in bgp and just send it across

1:46:20 and then we can have distributed layer 3 Gateway capabilities or we don't have to

1:46:26 have different uh Gateway addresses those Gateway addresses will basically

1:46:31 reside on all the edges in each of the vlans all right so let's see how this vxlan

1:46:38 tunnels kind of works so here we have host one on the left hand side and the TR going to try and send traffic over to

1:46:45 host 2. there's a layer 2 frame that gets put on to the line looking for the MAC address

1:46:53 of host 2. the leaf one will take that layer 2

1:46:59 frame and encapsulate it using vxlan IP to put a layer 3 address on it to send

1:47:08 it across the IP fabric we create that vxlan tunnel using the

1:47:14 vteps right the virtual tunnel endpoints from Leaf 1 to Leaf 6 and we'll go ahead

1:47:19 and put it in that tunnel week six gets that packet D encapsulates it and then

1:47:26 puts the frame back out onto the wire to head to host two just like if they were

1:47:33 on the same switch what are some of the benefits of using a evpn vxlan well we get consistent

1:47:41 scalable standards based architecture that we can use we can use multiple

1:47:48 vendors technology within the the fabric uh it's easily scalable we can just keep

1:47:55 scaling up as long as we have open ports on our spine switches we're going to use a common framework

1:48:01 now both on our campus and our data centers so that the learning curve for the different platforms are lower

1:48:08 we're going to reduce the flooding and learning uh on our networks so a lot of

1:48:13 the traffic that gets put out there will just be removed now uh Mac addresses can be moved around a

1:48:22 lot easier we don't have to worry about exactly where they're at the evpn will learn them and and just advertise them

1:48:29 out and we can segment our Network a little easier

1:48:35 well we've reached the end of this course and we're so happy that you've taken time out of your busy schedule to

1:48:42 be with us to learn more about Juniper Networks and the junos operating system

1:48:47 we sure hope that you have found this very useful but you might be thinking well what's

1:48:53 next now that I'm done with this course attend another jumpstart Juniper class

1:48:59 you can sign up at the URL on the screen we have six courses right now that cover

1:49:06 junos please watch for more jumpstart Juniper videos coming soon

1:49:11 another fantastic resource is the learning portal at juniper.net there you'll find a lot of resources

1:49:17 that can help you one of those is the Juniper open learning Juniper open learning is for

1:49:24 certification and to help people get started with their certifications

1:49:29 Juniper open learning has live seminars where you can ask experts questions about the things you might need to know

1:49:36 about the certifications they also have some online videos that

1:49:41 you can watch that go over the certification information and help you

1:49:47 learn the things that you need to know they also have practice tests you can

1:49:53 receive vouchers if your pass those practice tests to receive a discount on

1:49:58 your test that you need to take to become Juniper certified so make sure

1:50:03 you check out Juniper open learning another thing is the learning paths that you can find on the learning portal the

1:50:10 learning paths help you decide which track is best for you is it security is

1:50:15 a service provider Enterprise what things do you want to learn from Juniper

1:50:21 Networks On The Learning portal you'll also find all the on-demand courses from

1:50:27 the course development team from Juniper Networks they have many courses for you

1:50:32 to take on the different technologies that Juniper Network provides so that

1:50:37 you can learn and grow in the path that you want there's also a list of class schedules

1:50:44 for scheduled classes that are led by an instructor last of all is the all-access

1:50:50 pass this all access pass allows you to take any course the Juniper has this all

1:50:56 access pass is a yearly subscription for you so that you can take as many classes

1:51:02 you'd like throughout the year it's a single price and it also comes with a

1:51:09 few perks and one of those perks is that you can take an actual class from one of

1:51:15 the class schedules so you can take the on-demand course and then you can actually take it from the

1:51:21 instructor so that really helps you be able to find the path that you want to

1:51:27 take Juniper Networks has created a certification path just for you

1:51:33 this certification path will help you distinguish yourself amongst your colleagues that you know how Juniper

1:51:40 Networks operates and how to design and maintain networks built by Juniper

1:51:47 Networks equipment there's four levels within the certification path that you can take

1:51:53 there's an associate level a specialist level a professional level and an expert level

1:51:58 at each one of these levels you get to show how much you know about Juniper

1:52:04 Networks operating system and devices each one of these certifications can run

1:52:11 within a different track Juniper Networks has seven tracks that you can pick from to show your

1:52:19 Proficiency in Juniper network devices and configurations

1:52:24 these tracks are service provider routing and switching Enterprise routing

1:52:29 and switching data center Juno security Cloud Automation and devops data center

1:52:35 Wan security design so there's a track for you to be able to

1:52:42 move forward and show that you are proficient with Juniper Networks devices

1:52:49 thanks again for attending our jumpstart Juniper course today