Juniper Networks (UK) Limited
HOW TO DEPLOY JUNIPER EX SERIES
SWITCHES IN YOUR CAMPUS NETWORK
10 June 2009
WITH SCOTT CALZIA, YONG KIM AND TING ZOU
Transcript
Duration: 01:31:57
Operator: Thank you for standing by and welcome to the How to Deploy
Juniper EX Series Switches in your Campus Network conference call. At
this time all participants are in a listen only mode. There will be a
presentation followed by a question and answer session at which time if
you wish to ask a question you will need to press *1 on your telephone. I
must advise you this conference is being recorded today, Wednesday
June 10th 2009. I would now like to hand over to your speaker today,
Scott Calzia. Please go ahead sir.
Scott Calzia:
Thank you very much. Good morning, good afternoon
everybody. Thank you for joining us today. Today we are going to have a
presentation on deploying Juniper’s EX Series Ethernet Switches for the
Campus. Hopefully now you have the presentation up there. My name is
Scott Calzia and I am a senior manager for product marketing with
Juniper’s Ethernet Platforms business group and you will see me up there
on the camera as the one speaking and the other person hopefully you
now see up there on the camera is Ting Zou. Ting, why don’t you
introduce yourself?
Ting Zou:
Yes, I am Ting Zou, I am the technical marketing engineer from the
Juniper EP business group.
Scott Calzia:
And Ting will be joining us, he will showing a lot of the
demonstration that we have for your today as far as the command line
interface for the EX Series. We also have a third participant or presenter
1
today, [David Nguyen] who is there in the background. Any questions that
you may have for us today; go ahead and use the question and answer
screen that you see there up on your screens hopefully. And David will be
in the background and he will answer those as quickly as possible. We
will also spend some time here at the end today and we will also some
questions as well. I see a couple of comments coming up that there is an
echo. Note that we have here—we are using a speakerphone that we are
speaking into, we are also using our laptop microphones, and only one of
our laptop microphones is enabled. So that folks who are using their
laptops or their computers to listen in, can hear us and also those people
who dialled into the conference can hear us through the speakerphone.
Hopefully you know I hear that there may be some echoes out there but
from our end there is nothing that we can do on our end. Make sure that
you don’t have a speakerphone on as well as your laptop speaker
because that will cause an echo from your end because they are typically
not in sync.
So with that, let’s get started. So again configuring EX Series Ethernet
Switches for the Campus; we have a presentation for you today. We will
go through some slides. Those slides will talk about some of the theory.
In other words we have a few things that we will talk about and then I will
turn that over to Ting every once in a while, he will go actually and show
some of the CLI commands and then he will actually go and bring up the
CLI screen and show you the demonstration with the EX Series. We do
have a couple of devices that are setup today and we have also have a
little bit of a reference architecture here and what you see on this slide that
I have just brought up, the legacy Campus LAN architecture. And this is
what we are going to use pretty much for today to talk a little bit about the
Campus. Now this is what we would call a typical Campus. Were we
have got two buildings in this particular case. Each building a number of
[wiring closets] you can four wiring closets per building. We have
aggregation layer where we are aggregating those multiple wiring closets
into aggregation switches and in turn we are aggregating those into core
switches. Now this is the reference architecture that we are going to be
using today, but keep in mind this not the demonstration that we have set
up. The demonstration that we have set is off camera, you’re not able to
see it, but it is comprised of several EX 4200 Ethernet Switches. The EX
4200 is a fixed form factor, 48 port or it comes in a 24 port model, a 10,
100, 1,000 device with a number of—or with optional uplink modules.
Those are the devices that we are going to use today for the CLI and you
2
will see as we go into the CLI screen, you will see a lot of the EX 4200.
But for the purposes of our discussion today on the Campus architecture
we are going to use the attached here as the reference architecture for
that.
So let’s get started. So what you see up there with the legacy Campus
LAN architecture are a number of wiring closets, typically you have got
stackable devices or in some cases modular devices in those wiring
closets. Typically the uplinks from those wiring closets into the
aggregation are usually oversubscribed; you have got a lot of devices
sitting out there at the wiring closet; 10:100 or 10:100 and 1,000. Those
are interconnected into switches and an aggregation layer which in turn
are oversubscribed and connected into a core layer. This particular
example that you see here, if you counted the number of managed
devices on there, one per wiring closet, two in each of the aggregation
layers, two in the core, you would have 14 managed devices. Now
Juniper with the EX Series can actually simply that architecture by utilising
the EX 4200 with the virtual chassis technology. And the way that we do
that is we deploy the EX 4200 in the wiring closets, the EX 4200 again a
fixed form factor device, 24, 48 ports, ideally suited for wiring closet
access types of deployments. The EX 4200 has something—what we call
the virtual chassis technology which is the ability to interconnect multiple
physical devices into a single logical device.
Now what we do is we can extend that virtual chassis across multiple
wiring closets as you see in this particular diagram and we will talk a little
bit about how we do that in the next couple of slide, but the key advantage
of the virtual chassis, you really can simply the design of the Campus
because instead of looking at a Campus design on per wiring closet basis
and deploying physical switches in a wiring closet, perhaps connecting
those in a stackable type of configuration and having a single logical
device per wiring closet, you can actually extend that virtual chassis
across more than one wiring closet. Two, three, four all the way up to ten
wiring closets if you only had 48 ports per wiring closet location. And the
advantage there is that you actually simplify the overall design, reduce the
number of managed devices within a Campus location. Now in the
previous example we showed a legacy design where there were 14
managed devices, by deploying the virtual chassis across pairs of wiring
closets in this particular example, we can reduce that down to ten
managed devices.
3
So one of the advantages of the virtual chassis in this environment is
simplifying the management; reducing the number of logical managed
devices within that environment. So the virtual chassis simplifies the
access, it reduces the number of managed devices within that access by
being able to extend the virtual chassis across multiple wiring closet
locations, reducing the number of logical devices that you would manage
in a Campus environment. In addition to that and another advantage of
the virtual chassis in the access is the ability to reduce the number of
uplinks. In the past in legacy environments as we deploy devices at a
wiring closet level, we would always want to have at least a pair of uplinks
from each wiring closet back into the aggregation and back in to the core
and we typically did not only for performance reasons but also for
redundancy reasons. Well now we have much more flexibility when we
can extend the virtual chassis across two or greater wiring closets
because we can also distribute those uplinks across the wiring closets.
That allows us to physically reduce the number of uplinks and we no
longer necessarily need to have a pair of uplinks for every wiring closet,
we can have a pair for a pair of closets or a pair for up to ten closets as
one extreme. And we can really design the network based on the
performance needs of the network, not based on the physical layout of the
Campus network.
So the virtual chassis again just in review, because I know we had some
audio problems so I will go back through that fairly quickly. The virtual
chassis using the EX 4200, which we can have multiple physical devices
configured as a single logical device supporting up to 480 ports, we can
extend it across wiring closets and it gives us two advantages. One is to
reduce the number of logical managed devices and the second is to
provide the flexibility of performance as well as reducing the number of
uplinks within those locations. So with that, because the virtual chassis is
very important I am going to go through very quickly what is a virtual
chassis? I have mentioned it a number of times here but essentially the
virtual chassis is utilising Juniper’s EX 4200 Series Ethernet Switches
which is a fixed form factor, 24, 48 ports device as you see here on the
screen. And interconnecting that across multiple physical devices, up to
ten of these devices, to form a single logical switch which in concept is
very similar to a stackable that has a number of very important differences
and the reason we call a virtual chassis and I will discuss those here in
just a minute.
4
The first is simplified management. A single management interface, a
single implementation of JUNOS software and that includes a single
configuration, a single image file and then a chassis like slot, module and
core numbering scheme which is consistent with other modular platforms
within Juniper’s portfolio including the EX 8200, including the NX Series of
Ethernet services routers. A simplified design, the ability to extent for
example a link aggregation [group] across multiple members of that virtual
chassis and again that is a very important concept as we extent that virtual
chassis across multiple wiring closets, being able to distribute those
uplinks across physical numbers of that virtual chassis perhaps extending
those uplinks across multiple wiring closets and giving us the flexibility for
performance, reducing the number of uplinks required in a design.
Resiliency; the virtual chassis has the ability to have master as well as a
redundant route engine or control plane. Each device within—or each
member of a virtual chassis has ability to become the master, each
member also has the ability to become a backup. This gives you an
unprecedented level of reliability because if have ten devices within a
virtual chassis, essentially you have up to ten levels of redundancy built in.
You can essentially allow the master and the backup to be determined
dynamically or you can statically define these devices if the needs require
it within your environment. In addition to that each EX 4200 has
redundant power, redundant fans—has the option for redundant power as
well as the redundant fans.
The flexibility of the virtual chassis of course allows you to add additional
devices within that virtual chassis. If you start off with say 48 ports in a
wiring closet and you need to add additional ports, you simply can add
another member to that virtual chassis and it becomes part of that single
logical group. Additionally you have the flexibility of uplinks. The device
can support a modular uplink module for other either gigabit optical or up
to 10 gigabit optical uplinks within a fully configured virtual chassis of ten
physical devises, up to 480 fixed Ethernet 10, 100, 1,000 ports and the
ability to support an additional 40 gigabit or 20:10 gigabit uplinks. And
then lastly performance, all interfaces—within an EX 4200—are [wire rate]
interfaces. That includes the 10, 100, 1,000 interfaces as well the gigabit
or the 10 gigabit uplink ports. There is no trade off by adding 10 gigabit
uplinks and loosing some of the front panel ports. All ports are fully wire
rate. A virtual chassis can fit in a very small amount of space. Each one
of these devices is a single wrack unit, so a fully configured virtual chassis
5
would be only ten wrack units, ideal for those small locations such as
wiring closets. It also has a very low power consumption as well as a low
initial cost. Power consumption you are looking at about 170 watts
maximum per device, a fully configured virtual chassis with 1,700 watts
typically less than a modular chassis only supporting a fewer number of
devices.
So with that I am now going to turn it over to Ting who will go through our
first demonstration. Because we have talked a lot about the virtual
chassis, the first item that we want to speak of within the demonstration is
how we are going to go and set up a virtual chassis. So, Ting I will turn it
over to you to walk through that.
Ting Zou:
Thank you, Scott. I pull out my terminal window so there may be
some delay, so bear with me for a moment. Okay, so right now we have
two EX 4200s connected to each other, so I am going to demonstrate how
do we provision in the virtual chassis. So first we need to assess the
virtual chassis as a provision mode and then we need to set the virtual
chassis as a router engine, we set the virtual chassis, member zero, [the
row] the route engine. And we also need to assess the virtual chassis
member zero, [put a serial number] as a member zero, which is
BM0208380442. I just double check where I put the right number. Okay
and then we are going to configure the second switch in this virtual
chassis, which is member one. We set the member one row as also route
engine, which will become the backup of the virtual chassis actually. And
we are going to import the serial number for the second EX switch,
member one serious number BM0208372677.
So basically what I did is I completed two of the switches, the master and
the backup. And if you have the third switch which is going to join the
virtual chassis later, you can do the provisioning now. That is virtual
chassis number two which is the third switch. You can do the row, the
[unclear]. Basically this command line makes the third switch will be the
[unclear] it won’t be selected as the master or backup. So the same thing
we also need to put the serial number for the third switch, member two,
serial number BM0208372444 for example. Actually this switch hasn’t
joined the virtual chassis yet. So we do commit sync and the one thing
you need to remember is in virtual chassis whenever you do the commit,
you want to do the commit synchronise. Basically it will push the
6
configuration also to the other switch in the virtual chassis such as backup
and the master.
Scott Calzia:
So although, Ting, you only have a single config file by
synchronising it you are actually pushing that configuration file across.
Ting Zou:
Yes a cross over to all the members.
Scott Calzia:
So just a question to help the folks on the call; so
configured, you have pre-provisioning mode where you have configured
the actual master routing engine as well as the backup routing engine. Is
it also possible to allow a virtual chassis to elect those dynamically?
Ting Zou:
Yes definitely. If you want to make the virtual chassis elect
dynamically, you don’t need to config anything. You just simply connect
the two EX switches together. They will form the virtual chassis
dynamically as long as they have the same software version on each
switch.
Scott Calzia:
Alright, so you essentially have an option where you can
take it out of the box, plug each device and interconnect them up and it
will go through them dynamically and configure the virtual chassis to be
redundant with the master and the backup. Or if you have a need within
the environment, you can do what you just did here, which is essentially
pre-provision the devices and define a master and define a backup.
Ting Zou:
Exactly. Another thing I want to imagine is in the virtual chassis;
usually we enable the [unclear]. Basically it is graceful restarts for the
router engine switch over. So here I am going to enable the [unclear] third
chassis redundant, graceful switch over. Basically it will add the
redundancy for the virtual chassis, once the master fails the backup will
over with very less impact for the traffic.
Scott Calzia:
Ting Zou:
So essentially a hit list type of failoverExactly.
Scott Calzia:
-if the master should fail then the backup will take over.
Now, Ting, tell me so if a master does fail in a virtual chassis, the backup
will take over and as you just mentioned here it will take over with a hit list
7
type of fail over. Will another one of the devices, another member of that
virtual chassis then become a backup?
Ting Zou:
So basically when the backup takes over another round of election
will happen. Basically it will select the new backup switch in this virtual
chassis. So eventually we still have one master and one backup in the
virtual chassis.
Scott Calzia:
Ting Zou:
Alright and this all happens dynamically?
Exactly.
Scott Calzia:
Okay, now let’s say I was doing a pre-provisioning where I
have defined a master and a defined a backup, the master fails, the
backup takes over as master. What if I had another device that I wanted
to make sure would take over as the backup, is it possible to do that?
Ting Zou:
Sure, if you want to have another device which has a possibility to
become the master or backup. Basically you can set—another command
you can set the virtual chassis, for example member three. You don’t put
any row for this member three which means it has a possibility to become
the master of backup.
So now I am going to give it back to Scott to continue the presentation.
Scott Calzia:
So thank you, Ting. So you walked through a couple of
piece of how to configure a virtual chassis. Now Ting showed you how to
do that in a pre-provision mode and as we mentioned walking through that
there is also the dynamic mode which will enable it automatically. Now
some of these concepts, hopefully they are not new. If they are some of
the concepts of master and backup and members and line card roles and
graceful restart et cetera are new, I would encourage you—we have a
previous session that has been recorded. It is available to you folks on
virtual chassis and it goes into much greater detail on the virtual chassis.
How to configure it, the various roles of the different members et cetera
and I think that has a much more detailed overview than what we did
today. But we wanted to give just a basic view of the virtual chassis,
because it is extremely important in the configuration of a Campus LAN
design with EX switches.
8
So another piece of the virtual chassis and a very important piece for the
virtual chassis is the ability to extent that virtual chassis. We didn’t go
onto a lot of detail earlier, but essentially the virtual chassis on the rear of
the unit has a pair of interfaces, what we call virtual chassis ports. These
provide the interconnectivity to create a 128 gig per second ring typology if
the devices are roughly—I wouldn’t say next to each other but within a five
metre distance. So you can create a virtual chassis ring using these five
metre cables of over about 20 metres in length or I guess in height or
breadth depending on how you deploy the devices within a location. But
typically with the virtual chassis cables from the rear of the unit, you are
limited to deploying those within a single physical location such as a room
or a wiring closet. Now you have also the flexibility or the option to extend
a virtual chassis across much greater distances and the way that you can
do that is using the front panel optional uplink ports; either gigabit or 10
gigabit uplinks can be used to extend that virtual chassis and essentially
the limits of that extension are the limits of the optics. So the gigabit
optics, available today up to 70 kilometres and 10 gigabit optics today is
up to 40 kilometres. So you have the ability to extend a virtual chassis
certainly across wiring closet locations within a riser, within a building, but
even can extend that across buildings. And that concept will become
important here in just a minute as I walk through this.
So if we go back to our reference Campus design and we talked about the
access and extending the virtual chassis across multiple wiring closet
locations, we also have the ability to deploy the virtual chassis within that
aggregation layer. What you see as that middle layer there with the boxes
labelled IDF or Intermediate Distribution Frame. And we can deploy EX
4200s within those locations. Typically we would deploy the 24F model
which is 24 ports of SFP if you had gigabit uplinks back from the wiring
closets. And we can deploy a number of devices there. We could deploy
a single device or we could deploy multiple devices for redundancy.
Essentially up to a full virtual chassis of 24Fs, up to 240 gigabit ports and
creating a single virtual chassis within that environment. To complete our
overall design within the Campus architecture, we would deploy—well if
we deployed the virtual chassis there, again we could reduce the number
of managed logical devices within the environment. And we went from 14
where we started out with our each wiring closet as a single managed
location; we extended the virtual chassis across the wiring closets and
reduced that to ten managed devices by deploying virtual chassis within
9
the aggregation layer within those Intermediate Distribution Frames we
can reduce that down to eight managed devices.
Now if we continue to build out the Campus LAN architecture, we would
typically deploy the EX 8200 which is Juniper’s EX modular platform within
the core of the LAN environment. The EX 8200 comes in two options, an
eight slot or a 16 slot device. Each slot can support up to 48 ports of SFP
for gigabit Ethernet fibre connections or eight ports of 10 gigabit Ethernet.
So essentially within that core environment you can support up to 128 10
gigabit interfaces or over 768 gigabit interfaces; so very highly scalable
type of platform for large Campus types of deployments.
Now as we move into the net slide—and I will build this out because some
of the builds are a little odd on this particular case—but we can use that
extension of the virtual chassis to actually collapse what we would call the
collapse or consolidate both aggregation and core into a single layer
moving from a three layer model of access, aggregation and core in the
legacy environment to essentially just an access and a core environment
with this collapsed model. And the way that we can do that is again
utilising the EX 4200, the 24F models if we are going to be collapsed
gigabit Ethernet into that core environment and we can extent the virtual
chassis across multiple buildings as you can see here. Now in this
particular example we show a pair of virtual chasses, core VC1 and core
VC2 and that would be the best practice or the recommended practice
because you would have a pair or a redundant set of virtual chasses for a
maximum availability.
Now this design if you had a pair of virtual chasses you would deploy a
single EX 4200 and 24F within each building location. You can support up
to 24 uplinks from each of those locations with that particular
configuration. You can extend that virtual chassis across five buildings
and a campus type of environment. This really is the maximum simplicity
that the EX can offer within a Campus type of architecture. Up to ten
Intermediate Distribution Frames per VC, typically across ten buildings
with a pair of these virtual chasses for redundancy and again reducing or
simplifying the overall management architecture by now having only six
managed devices within this Campus location. If you looked at a total cost
of ownership analysis and we have a number of documents and things
that we can show this in and I will share those with you towards the end of
the presentation. But if you looked at a traditional or a legacy Campus
10
environment and you compared that with this simplification utilising the
virtual chassis you could actually realise a savings of about 45% total cost
of ownership and that includes capital expenses as well as operational
expenses of managing this particular environment so very significant cost
savings within that.
And again this development uses the virtual chassis or the extended
virtual chassis, the ability to use those uplinks across great distances; 40
kilometres with a 10 gigabit Ethernet or up to 70 kilometres with gigabit
Ethernet. So at this point it is a good point to turn it again back over to
Ting who will talk about configuring an extended virtual chassis. By
default I should note that the uplink modules themselves are utilised for
typical uplinks. If they are going to be utilised as virtual chassis interfaces
then they have to be configured as virtual chassis interfaces and that is
what I will turn over to Ting now and he can walk through that very briefly.
Ting Zou:
Thank you, Scott. So basically we have the uplink module on the
member zero switch in the virtual chassis. So what we can do is we can
turn this uplink module port then render a natural port into the VC
extension port; so I can show you how we can do this. So basically you
can request—we can do a show interface test. So basically you can see
we have the uplink port on the member zero which is [8B010]. Right now
it is a regular network port. So I am turn this regular uplink network port
into the VC extension, basically you type the command request virtual
chassis VC port set pick slot, which is in this case the slot is number one
and the port number is zero. And then I put the member zero.
So by this command basically I turned this regular network port E0/1/0 into
a VC extension port. So how to verify that; we can use the command
show virtual chassis VC port. So in the output of the command you can
see we have two regular VC ports, which is VCP0 and VCP1. Now we
have another VC extension port, it is P-0010 which is [unclear] regular
uplink port. Right now it is config’ed as a VC port but since we don’t have
any link on that port so it shows down. Once you connect the fibre to this
link and to another EX switch, they can phone the VC through that link.
So another command I want to show you if how do you delete this VC port
and turn this VC port back into the network port. So basically we can do a
request virtual chassis VC port delete pick slot number one and the port
number zero member zero. So basically this command will turn this VC
11
extension port back into the regular network port. So we can do another
show virtual chassis VC port. Now you can see you don’t see the VC
extension port. You only see two regular VC ports. So I am going to turn
back to Scott.
Scott Calzia:
Thank you, Ting. So the next concept that we want to
discuss, we talked a little bit about the architecture, we talked about how
we can simply the architecture utilising the virtual chassis within the
access, utilising virtual chassis within the aggregation and how we can
collapse the aggregation as well the core utilising the virtual chassis. The
next concept that we want to talk about is using or deploying layer two and
layer three as well as increasing the availability within the Campus. And
the EX has some key characteristics and some key advantages where we
can actually increase availability at no additional cost for Campus types of
deployments. So a traditional Campus deployment and again we have
our reference architecture up here and we have go the virtual chassis
there deployed in the access and we have got it there in the aggregation,
we will just go with a three tier type of model and we will put EX 8200s in
the core and you can see these are generic icons on the slide that you
have in front of you. But a traditional type of deployment is going to
provide those default gateways at the aggregation. Typically the layer
three boundary is going to be there at the aggregation layer and where
they are going to deploy layer two with spanning tree up there at the
access.
Now that is certainly something that can be easily deployed with the EX
Series. It provides redundant standby links typically in that environment.
If you looked and you did a cost comparison, a total cost of ownership
comparison you would typically find that because you deployed the virtual
chassis and the wiring closets within the aggregation layer and you have
simplified the overall infrastructure you still have a significant TCO savings
within that environment and this is certainly fine. Now one key advantage
again of the EX is the ability or the fact that the EX series—the EX 3200,
the EX 4200, the EX 8200—within the base units also support full layer
three dynamic routing protocols, including RIP, including several other
multicast protocols. The advantage there is that you can actually deploy
layer three all the way to the access and make the default gateways at the
access.
12
Now I know a lot of folks out there are probably saying well hold on a
second I don’t want to have and configure layer three interfaces for all of
my edge devices and no that is not what we are proposing. Essentially
what we would propose in this environment is to deploy layer three to
those uplink interfaces and because the EX 4200 devices have the ability
to configure layer three on a per port basis, we can just define the layer
three interfaces as those uplink types of interfaces.
Now a couple of other things, typically we get back from customers is wow
you know putting layer three out at the access is very complex. I mean it
is difficult to configure, it is much harder than layer two. Well that actually
is not entirely true. Actually configuring layer two versus configuring layer
three is really a wash, it is identical to one another. There is not a lot of
differences from number of commands. I mean obviously the commands
are going to be different. What deploying layer three at the access does
require is a little bit of pre-planning as far as an IP addressing scheme, but
the trade off for doing that is a vastly increased availability. Essentially
what you have are faster failover times, typically sub-second failover in a
layer three environment as opposed to seconds up to maybe minutes in a
layer two environment. You also have the ability to define much smaller
failure domains, so that in the event of a failure within an environment it
may only impact a few users perhaps in a wiring closet type of location as
opposed to multiple wiring closets or a full building, perhaps 1,000s of
users. So smaller failure domains, faster failover times actually increases
the availability of the Campus environment by deploying layer three out to
these access uplink locations.
Now the other key thing that customers come back and say well the layer
three up to the access we well that is very expensive. Well we have taken
that whole cost argument off the table by providing the layer three
capabilities within the EX Series of platforms and again having as part of
the base unit the ability to support such protocols as RIP, OSPF, equal
cost and multi path. No additional licensing fee, there is no additional
code that you need to put in to enable these features. They are there by
default.
So again if you did a cost comparison, we looked a the cost comparison
with a layer two, layer three using the simplified type of architecture, if we
look at a cost comparison with layer three, because there is no additional
licensing fees you can actually save up to about 40% in the total cost of
13
ownership analysis by deploying layer three and comparing that with other
ventures deploying layer three to the access. So again I am going to turn
it over to Ting who is going to go through very quickly on configuring
OSPF, configuring this layer three at the access. And again as part of our
demonstration we do we have Ex 4200s but it won’t make any difference if
you had an EX 3200 or an EX 8200, the configuration would be identical.
So, Ting I will turn it over to you.
Ting Zou:
Sure. So just like Scott said the [unclear] is we can configure
OSPF even within the basic license, so it allows for [unclear] three
features. So I already pre-config’d two interface into the layer three
interface. One is the interface gate E0/0/23. We can take a look at what I
have already pre-config’d. And another interface is show interface gate
E0/10/23 which is on the member one. We can config this one also into a
layer three interface. Now I am going to complete the OSPF. Basically
you need to config OSPF on the protocol standard. So [unclear] protocol
OSPF [area zero] and the [unclear] interface, gate E0/0/23 and also you
can put the authentication method. Now in this example we are going to
put ND5 as our authentication method and then you put the key ID. In this
example I just put 200 as a key ID. There I put the key [unclear] is—that
part is secure, this is just random name I come up with. And also you can
config OSPF [stub area]. You can do set protocol OSPF area one, we can
config the area one into the start OSPF area. You can put there start and
we also configure another interface into the area one interface gate
E1/0/23 which is—this interface is on the member one. And another way
you can also put this Gate E1/0/23 as a passive interface basically it won’t
send an OSPF allow throughout that interface. You can reduce the
[unclear] on that link. Basically you can simply put the passive on this
command.
So another thing we can config is we can config that ECMP for the OSPF.
So in that layer three through the access design a lot of times we need to
config the ECMP load balancing for the OSPF for the access switch to
route the traffic out to the aggregation layer.
Scott Calzia:
So Ting I am going to jump in for a minute because I see
you can type in a few things and it is asking for [unclear]. I noticed as you
were typing in some of the OSPF commands there was a typo error and
that is fairly common. Just a question, so as you go and actually configure
14
the devices and you are using the command line here, are those changes
taking place dynamically on the devices?
Ting Zou:
Basically you can see when I have done a typo and through the
[unclear] for JUNOS it will automatically check typo errors in the [CR] you
type in. So it will give you the message okay you have done a typo.
Those mistakes will not be commit in.
Scott Calzia:
That is right; and so I mean you have to commit those
changes because any changes take place. So if you actually did not
make a typographical error but you actually configured say the wrong IP
address or there are many other examples, but essentially made an error
in configuring the device that you didn’t intend to make, it actually won’t
take effect on that device until you have committed it?
Ting Zou:
Yes it won’t take effect and also it will give you some warning
message and it won’t allow you to commit that.
Scott Calzia:
These various protocols that you have configured, obviously
in OSPF configuration it was very straightforward, but you talked about
stub areas, you talked about the authentication piece and next you are
going to talk a little bit about equal cost multi path, typically in a Campus
environment which of those would you use? You would use OSPF
obviously—would you use stub areas, would you use the authentication
would you equal cost multi path in those environments?
Ting Zou:
Exactly. So if we talk about the layer three to the access switch in
the Campus department, usually we use OSPF down to the access
switch. Also we configure the OSPF stub area for the access switch. And
also we enable the ECMP to load balance the traffic out to the access
switch.
Scott Calzia:
Ting Zou:
Right so it gives us an advantage I guessExactly.
Scott Calzia:
-where we don’t have standby links, we have active links
with load sharing.
Ting Zou:
Sure. So next I am going to show how to config the load balancing
with the OSPF ECMP. Basically you need to set policy options and then
15
put the policy [statement]. We just put some [unclear] ECMP. Then load
the balancing, basically you can packet those balancing mechanisms.
Then we set the routing option, forward table, fixed port, the policy name
which is ECMP [reconfig] then we do the commit. So here you go, so
basically the traffic will do the load balancing with the packet—per packet
load balancing. Okay so I am going to turn back to Scott to continue the
presentation.
Scott Calzia:
Great. Thank you, Ting. So now let’s move onto a new
concept; we talked about the layer two, layer three configuration, next
thing let’s talk about is deploying unified communications within a Campus
environment. Obviously [unclear] communications and the ability to
deploy voice devices and utilise the data communications infrastructure
within that environment. So the EX Series has some capabilities that we
can do that as you can see here on the screen, you can read as easily as I
can, the ability to auto-sense the IP phone connectivity. So using LLDP or
LLDP [MED] protocols we can do that. The diagram that you will see up
here shows EX 3200 but actually LLDP and LLDP MED are available on
the EX 3200 as well as the EX 4200 Series of products. We can also
provide [8200] access control for multiple supplicants, so that is important
for connectivity of unified communication devices. And then from a
physical standpoint, [audio]; the EX 3200, the EX 4200 as well are
capable of full class three power over Ethernet, meaning class three 15.4
watts per interface. So oftentimes we are asked what is the—how much
power to do I have available for each one of my ports and what is my
power management capabilities of the switch? Well essentially it is very
easy. All the ports are powered and there is no power management
function because we do provide class three power on all interfaces within
the EX 3200 as well as the EX 4200.
Now a lot of other vendors will go and they will provide a power over
Ethernet device and you can get power over Ethernet ports but typically
you have a budget and there always needs to be a management interface
or some type of management infrastructure behind that on how you
manage the power budget. Not the case with the EX Series. It is very
simple, all the ports are powered and there is no power management.
Now of course we do offer devices that I would say do not have power
Ethernet and I guess other vendors offer devices with no POE capabilities.
Well there are models of the EX 3200 and the EX 4200 with what we call
16
partial POE, we don’t offer a non POE capable device. We either offer full
POE or partial POE. And the reason we do that is because it is always
expected that within environment where you will deploy the EX Series you
will always have a need for—if you don’t have IP phones and you’re using
power over Ethernet for all devices well you still may have cameras or
wireless access points or a few devices that are going to require POE. So
we offer that capability of at least eight ports on the EX 3200 or the EX
4200 Series will have power over Ethernet capabilities. So you have
various models of available. You either have a partial POE with eight
ports of class three, or you have full POE with all 24, 48 ports of class
three POE.
Now also within the EX Series devices there is the ability to support
multiple queues, very important for prioritising the business critical
applications such as voice application, as well as the [ACL] support where
you can get up to 7,000 entries and we will cover that here in a few
minutes. I am going to take this opportunity to talk a little bit about LLDP
and LLDP MED. I don’t want to make it an educational session but
essentially EX Series supports the Link Layer Discovery Protocol which is
the layer two protocol that allows the network devices to advertise their
identity and capabilities within the environment. And essentially what it is
LLDP MED has the ability to support interoperability between voice over
IP end point devices and other networking end devices with the EX Series
of switches.
So I am going to turn it over quickly to Ting who is going to show us how
to go and configure the EX Series to support the unified communications;
specifically support LLDP and LLDP MED. So, Ting?
Ting Zou:
Sure. So basically for the LLDP and LLDP MED it is enabled by
default in the factory default. So we can do this [assure] protocol LLDP.
So it is LLDP and LLDP MED is enabled for all the interfaces on the
switch.
Scott Calzia:
So essentially if I have an EX Series 3200 or 4200 and I
plug it in right out of the box, so I just plug in voice over IP phones and it
would be recognised as a voice over IP phone?
Ting Zou:
Exactly. It is plug in to play, you don’t need to configure anything.
So since it is already config’d by the factory default, now I am going to do
17
some show command to show what we can see by the show LLDP
[neighbours]. So basically in our set up we have the switch connect to an
external EX switch. So basically you can see another EX switch the name
with EX 4200-13 is connected to this virtual chassis through two interfaces
actually. One is through the interface on the member zero which is
E0/0/23, another is the same switch is connected to the member one
virtual chassis which is E-1/0/23. And in this set up I also connect a
CISCO phone to this EX switch. You can see the CISCO phone is—the
name is CISCO default name, SEP0017 something like that .CISCO.com.
And the CISCO phone is connected to the port on the member zero which
is the E-0/0/21. So by the LLDP and the LLDP MED the EX switch can
discover this CISCO phone and provide the power to that CISCO phone.
So this is the output for the show LLDP neighbours. We can also do a
show LLDP details. So it will tell you more information for the LLDP set up
on this switch. So you can see the LLDP at a [unclear] transmit delay of
two seconds zone parameter for the LLDP which is default.
And another command is you can do show LLDP local information. So
basically it will tell you what local information is and what will be advertised
to the peer switch. So you can see the local information, the system name
is [NDANNY-IE0] and also has the local information for each interface
which is up or down. If it is up that means it connects to another device
which is also support LLDP and there is a last command I want to show
you, show LLDP statistics. So basically it would tell you some package
statistics for the LLDP. So what is the incoming package, what is the
incoming TRB and out coming TRB. So I am going to turn back to Scott to
continue the presentation.
Scott Calzia:
Thank you. So Ting showed there the configuration of
LLDP and LLDP MED and actually it is configured by default. There is not
a lot of configuration required but the one point I want to bring out is that
he showed the connection of a CISCO phone to the EX Series switch and
we have done a lot of interoperability testing and obviously Juniper is not
in the business of making voice over IP phones so we have to ensure
interoperability with other voice over IP devices that are out there. And we
have some documents as well and some video presentations on how
simple it is actually to connect multiple vendor’s voice over IP devices to
an EX Series product. That includes devices such as CISCO,
SHORETEL, AVAYA and we have also done testing with other vendors
that are out there. But I encourage you after today’s presentation you can
18
go online and we will provide some of the links at the end of that to show
the interoperability for some of these unified communications devices.
So let’s move on to our next concept which is port security and obviously
security is extremely important in any type of Campus or any type of LAN
environment for that matter. And the EX Series offers some port security
features that we will talk very briefly about and I will have Ting show the
configuration of each one of these. So the four that we have available are
the four that we will talk about today: MAC limiting which as you can see
here prevents the MAC flooding and spoofing by limiting the number or
configuring the number of MAC addresses on any given port. We also
have the ability to DHCP snooping and inspecting all DHCP packets. And
then the dynamic ARP inspection, again to prevent any type of spoofing,
in this particular case ARP spoofing and intercept ARP packets on an untrusted types of ports. Those are the three port security features that we
will actively show today. The fourth one which we will not show is the
reverse path forwarding which is a mechanism to cope with any DOS or
DDOS types of attacks or the [storage] address is spoofed in the
environment.
So very briefly on the theory piece but lets get into the actual configuration
piece and I will have Ting show you how to set up through the CLI MAC
limiting, DHCP snooping and dynamic ARP inspection.
Ting Zou:
So what I am going to show is, I am going to complete the
interface which is connected with a CISCO phone and I have put the MAC
limit to two, basically by enabling this feature the EX switch only allows it
when the CISCO connects with the EX switch port another PC behind the
CISCO phone can be connected with the EX switch port. So I am going to
show how I am going to do this. So basically you can set the MAC limiting
under the Ethernet switching options. Set Ethernet switching options.
Secure access port. And then you put interface…in this case I am going
to put the interface which is connect with a CISCO phone E0/0/21 and I
am going to put the MAC limit is two. And then I am going to continue to
config the MAC adjust for allowing the MAC.
Scott Calzia:
So essentially what I am doing is I am just allowing two
devices to connect to that particular port, port 21 in this case.
Ting Zou:
Exactly.
19
Scott Calzia:
And the intent here would be—or that the devices
connected to that port are an IP phone and a laptop.
Ting Zou:
Yes. So allow MAC…I put this is for example the IP phone.
Scott Calzia:
You already know what the MAC address, so you’re
essentially just copying it off here but that would be something that you
would have to know.
Ting Zou:
Yes. So for example this is a PC MAC address and the second
one I am going to config the IP phone MAC address which is E0896B. So
basically this is the IP phone MAC address. By completing this I am going
to allow the IP phone and the PC behind the IP phone can connect to that
port. You do a commit. Next I am going to config the DHCP snooping on
the [unclear]. I already put [unclear] and now I am going to enable DHCP
snooping on the [VLAN 13]. So [unclear] that Ethernet switch option
secure access port and there I put VLAN 13 and DHCP snooping enable
and also the same way you can enable the dynamic ARP inspection.
Basically set Ethernet switch options secure access port VLAN 13 then
enable the ARP inspection for the VLAN 13. Then the last thing is to do
the committing and push all the configuration to all the members in the
virtual chassis. Okay I am going to turn to Scott to continue the
presentation.
Scott Calzia:
Thanks, Ting. So continuing with our security theme, now
let’s turn to the access control. Juniper has an overall access control
solution which is called Unified Access Control and the EX Series
participates as part of that overall solution which is comprised of a number
of different pieces and parts. But essentially the EX Series role and the
Unified Access Control solution is to act as a point for policy enforcement.
So as part of the overall solution it includes a number of different Juniper
products, including the key piece which is the internet controller, or the IC
for short. And this is where we actually define the policies to provide
network protection, guest access, identity based quality of service and the
other [unclear] delay monitoring and application access that you see here
in the upper right corner.
In turn each one of those policies is downloaded to the EX Series where
that policy is going to be enforced and the IC can push this policy name to
the EX Series switch for dynamic configuration based on a user or device
20
level. And the policy on the EX Series can enforce specific quality of
service queuing or scheduling policies by VLAN assignment via any other
port configuration parameter. So the way it does that is through the—or
the way that it forces through 802.1x and again I am not going to spend
the time and make this an education session on 802.1x and authentication
but just to understand 802.1x very quickly it is the [unclear] standard for
the access control and authentication. It is supported by the EX 3200 as
well as the EX 4200 Series and that what is utilised with the internet
controller and to enforce the various policies within the Unified Access
Control environment.
So I wanted to go through that very quickly as kind of a set up and I am
going to now turn it back over to Ting who is going to talk about how they
go and actually configure 802.1x on the EX Series platform. So, Ting with
that over to you.
Ting Zou:
So basically we have three steps to config 802.1x on some
particular interface. So first we need to config the UAC our RADIUS
Server information, our IP Address, our password. So basically we set
access radius server…
Scott Calzia:
So what we are essentially doing here is just telling the EX
where the RADIUS Server is located?
Ting Zou:
Yes. And I put the RADIUS Server address here…and then I am
going to set the secret password. And the second step is we are going to
configure RADIUS profile. So we need to set access profile. We called it
TEMPUS and authentication order is RADIUS and the RADIUS
authentication server also. Profile TEMPUS authentication order.
Scott Calzia:
So you have actually defined a RADIUS profile predefined
and you’re just telling the switch what that profile is. So the first step you
told the switch where the server was. The second step tell the profile to
look for and then I assume the third step would be enable the interface?
Ting Zou:
Apply to the interface…exactly. And the third step I am going to
apply this profile to the interface to enable 802.1x. I can apply it to the
interface which is connected to the CISCO phone. And it is application
mode, I put [multiple] it basically allows a multiple device to connect to this
one. Okay so the last thing is to the committing, the [unclear] will be
enabled and the port which is connected to the CISCO phone.
21
Scott Calzia:
So Ting I know there are devices out there obviously that
have 802.1x capabilities but if I had to authenticate a device that didn’t
have 802.1x?
Ting Zou:
Exactly. So for some devices such as printers or some device
which doesn’t have the 802.1x support we can use the MAC bypass as an
alternative identification method. So set up as a MAC bypass is pretty
straightforward. You just need to set protocol .1x identification basically
you use the stat MAC address to authenticate that device on that port. So
I put a static MAC address for that device. For example when print has a
MAC address is 0A:33:34:34:34 and then I apply to the interface, E0/0/21.
So I enable the MAC bypass authentication method on that port. So if a
printer or some device connects to the port E0/0/21 and it doesn’t have
the 802.1x support they can use the MAC bypass to authenticate it.
Scott Calzia:
Great. So continuing on with our theme of security, let’s talk
a little bit about firewall [focus] or access control lists, ACLs. So the EX
Series has the ability to support essentially three different types of filters or
ACLs. The port based filter which you would apply directly to a layer two
switch port, or a VLAN based filter which is very similar to a port based
filter but you would apply it to a layer two VLAN or the router based filter
which you would apply to a layer three routed interface or RVI. Now these
are consistent with other devices within JUNOS as far as the filters PACL,
VACL and RACL and [unclear] support the same firewall filter can be used
as a port filter or a VLAN filter or you can deploy a router based firewall
filter and again it is very similar to other devices within the JUNOS product
family including EX 8200, including MX Series, including M Series et
cetera.
Now the firewall filtering takes place, the processing takes place—is done
in hardware and you will see that little acronym there, PFP or that is the
forwarding engine of the EX Series. So because it takes place in
hardware it can be done at [LAN] rate and it says there the firewall filters
are programmed into the [TCAM] on that forwarding engine and they are
performed at LAN rate. The EX 3200 and the EX 4200 can support up to
7,000 filters the EX 8200, the modular switch, will support up to 5,400
filters. So with that I am going to again turn it back over Ting who will talk
briefly about each one of those filters.
22
Ting Zou:
Sure. So I am going to talk about how you config or define the
layer two firewall filter and the layer three firewall filter. So basically if you
want to define the firewall which is going to apply to a port or VLAN you
need to set the firewall filter and the firewall family. So you can define the
firewall filter under the family Ethernet switch for example [unclear]. And
we can put some name as template one as a filter name.
Scott Calzia:
So essentially you are just defining a filter here.
Ting Zou:
Yes. You have a term for example it is term one, I match soft
address as a match criteria as a soft IP address.
Scott Calzia:
So essentially here Ting what you are doing is you’re just
defining the rule.
Ting Zou:
Yes. Access firewall family Ethernet switching filter… So basically
when the firewall filter detects any package from the soft IP address
10.0.0.11 it will discard the packet.
Scott Calzia:
Right. So simple [audio].
Ting Zou:
So if you want to set the firewall filter which is going to affect your
layer three interface, basically you do the same thing, set the firewall
family but it is on the I-net, it is not the Ethernet switch. So I am not going
to do this, basically it is the same thing. So the last step is you are going
to apply the firewall to a port or to a VLAN or to an L3 interface. Since we
already config’d a firewall filter which is defined on the family Ethernet
switch I am going to show how we are going to apply this firewall filter to a
port, a single layer two port. So we are going to set interface gate E0/0/21 which is again the port connected to the CISCO phone. Unit zero,
family Ethernet switching filter, input TEMPUS one; so basically I applied
to a layer two port and also you can apply this firewall filter on the VLAN.
So you can do set VLAN 13, you can do a filter input, TEMPUS one. So
this firewall filer becomes the [unclear] VLAN ACL. So the last thing is we
do the committing. So the firewall filter will take effect on the port or on
the VLAN L3 interface.
Scott Calzia:
Is there any way that I can show that those filters are [live]?
Ting Zou:
Yes. So basically we can do show firewall filter. You can see the
filter TEMPUS one [unclear] IP address 10.0.0.11 then you basically deny
23
this packet. And another way I want to mention, the default it is denied
and in the firewall filter.
Scott Calzia:
Okay, perfect. So let’s go back to our slides, this is our final
concept that we will talk about here and that is managing. So we have
talked about connecting within the Campus, how to simply the architecture
of the Campus, how to connect Unified Communication Devices, how to
provide some various levels of security within the environment. The last
concept is the management. There is a number of ways to manage the
EX Series and you can see five different ways that are listed here. You
have been seeing today in live format the JUNOS CLI which Ting has
been using to configure a lot of the concepts that we have been talking
about. The optional way is through a graphic interface which is the device
management tool for that, it is call J-Web and I believe Ting you are going
to show that very briefly as well. So we will have that out in just a minute.
The other network and security manager of Juniper is NSM, is a full blown
management application for discovery configuration, policy management,
inventory management as well as managing log information across not
only the EX Series of platform but also across other Juniper platforms as
well. Juniper’s security and threat response manager for BIOS levels of
threat detection, event log management as well as compliant [to IT]
efficiency and that coordinated with Juniper’s network and security
manager, NSM as well as for its full blown enterprise wide type of
management and security threat response management infrastructure. Of
course the devices are managed through SNP and through Syslog
information through other third party network management applications
such as IBM’s Tivoli and Vista EMC, you can see the different ones that
are listed there.
In the interests of time I think I am going to turn it very quickly over to Ting
who will walk us through the management. Obviously how to configure
management and how to configure the out of [band] interfaces and then
we will take a real quick look at the J-Web interface as well before we
conclude for the day. So, Ting with that I will turn it back over to you.
Ting Zou:
Sure. So first I am going to show how do we config the out of band
management interface. So since we have virtual chassis we are going
config the VME, Virutal Management Ethernet interface. So set interface
where the interface name is VME and then put zero family. I-net address
24
we put the 10.93.54.149. Then we do the commit thing and if you have a
standalone switch you can do the—set the management out of band
management interface the name is called ME0.
Scott Calzia:
With a single device, but if I had say a virtual chassis of two
or more devices, would I actually want to use that ME0 interface?
Ting Zou:
Yes you can still-
Scott Calzia:
You can still use that right, but is the recommended practice
to use the virtual interface? So you can actually use any one of the
physical devices as the out of band manager?
Ting Zou:
Exactly. So another thing is how we are going to set up the JWeb. So in this case we are going to enable J-Web through the [HTTP].
So we can set system service web management HTTP service.
Scott Calzia:
So essentially by default I don’t have the ability to use the
graphical tool J-Web to configure and manage these devices?
Ting Zou:
Scott Calzia:
No, you need to enable the HTTP service.
And that is for security reasons?
Ting Zou:
Yes. So another way you can manage the EX switch is you can
use the Juniper NSM, so we need to set up the system service. Again
also service [SSH] prototype version V2 and then we set [unclear] SSH
and then we set some SNP information view, we put the name ABC.1 and
include SNP. Basically this is SNP information immunity public…view
ABC, set SNP community public. Authentication [unclear] make it read
only for the SNP. So by this command, the above command you can
make Juniper NSM to manage the EX switch. So the final thing we do the
commit thing and later I am going to open web browser, IE web browser. I
am going to show—I am going to try access EX J-Web through the HTTP.
Scott Calzia:
Right. So you have configured on the switch the ability to
support J-Web. You also configured just to show everybody how to
configure NSM so they can manage devices. So now you are actually
going to try and open the J-Web screen and show everybody what J-Web
looks like. Now the things that we did today, configuring unified
communications with LLDP, configuring the various port security
25
functionality, configuring filters et cetera am I going to be able to do that
through the J-Web interface?
Ting Zou:
Yes. Most of the features you can do that through the J-Web
interface. So I opened IE web browser and I typed the HTTP
10.93.54.149. That IP address is a out of band manual address we just
config’d on the EX switch. So you can see there the log in page for the JWeb. So I put in the log in information.
Okay so in the J-Web you can see actually the device we manage through
the J-Web is the virtual chassis. It is two member virtual chassis and each
member is 24 port POE EX 4200 and this is also 24 POE Ex 4200. And
one is ID is member zero is the master and member one is backup. So
there is a lot of information in the J-Web you can see. And you can click a
single switch and do a rear view. So how many power supplies on the
switch and is it connected?
Scott Calzia:
In this case it looks like we just have a single power supply
and in the rear view there you also have on the left you have the virtual
chassis ports as green. So I assume that means that are interconnected?
Ting Zou:
That means the virtual chassis port is connected and you can see
it is 24 ports and also you can tell from this field you can tell what is the
version on the switch. We loaded a 95 JUNOS release and also you can
see number of active ports. We have three active ports on the switch and
total number of ports is 52 and the support of the MAC address table, all
the information you can tell. Another view is config so just like Scott
asked, we can config most of the features we showed today through the JWeb. So you can config the port…so it looks like there is a network
connective issue. Or even my PC issue. So basically we show the J-Web
how we canScott Calzia:
Essentially what we have with the J-Web interface is the
ability to have a graphical interface as an option to configuring and
managing the devices. As you saw there we have the two switches as
part of our demonstration lab today with the two EX 4200s and the virtual
chassis.
Ting Zou:
And even you can monitor the switch through the J-Web.
26
Scott Calzia:
Thank you for that, Ting. So we had a fairly heavy
schedule. I mean we went through and talked about a lot of different
things. We talked about how we can simply the architecture utilised in the
virtual chassis. We talked about how to configure the virtual chassis and
how to configure the virtual chassis ports of an extended virtual chassis.
Using layer three to increase the availability essentially at no additional
cost, how you would configure security, put in port security, access
control, firewall filters on the device and a very brief overview of
management. Obviously today you saw a lot of within the command line
interface, but also a very brief glimpse of the graphical tool with J-Web
and how to manage the device there. So that is our overview for using or
configuring the EX Series Ethernet switches for the Campus. I want to
thank everybody for your time today. I know I have seen David Nguyen,
our third member, you haven’t heard him speak much today but I have
seen him over here madly typing away and I see there are many, many
questions that have come in as a result of today’s presentation. So I know
David has been responding to those as much as possible. I am going to
open up the question and answer stream now—David, I think you have
been responding to everybody, so everybody has had a chance to see
what has gone on in the background.
So we still have a few minutes left in the session, I encourage you if you
have additional questions, please ask those now. I have got a whole
screen of those and I think since David has pretty much responded to
everybody on those, I don’t know if I will necessarily pick out any
questions to go and repeat again. I will also give it over to the operator if
anybody has a verbal question they would like to ask. So operator if
anybody wants to ask a question if you can let them do that.
Operator:
If you wish to ask a question, please press *1 on your telephone.
Scott Calzia:
While we are waiting for some questions, I will also point
you down here into some of the other screens, the download screen.
There is a number of documents available for you to download as parts of
today’s presentation. Campus Networks reference architecture. How to
go and deploy a Campus; following very closely the reference architecture
that we used today but also goes into a lot more detail about some of the
best practices in deploying the virtual chassis. Deploying unified
communications; deploying security with the LAN environment; more
detail than we had time to go into today. So that is a valuable document
27
for you to take a look at. The LAN design document goes down into even
more depth of configuration into designing the Campus LAN. And then I
believe further down in here there is an implementation guide on the
Campus. Unfortunately I don’t see that but there is an implementation
guide available but goes in different CLI commands and you will certainly
have today’s presentation available and Ting was kind enough to provide
some slides that actually talk about the command line interface or the
command lines that he was using in some of the demonstration today.
But we also have a Campus implementation guide that provides that detail
and that is available on the Juniper.net site and if you go into products and
look at under EX Ethernet Switching products you will find those
implementation guides there.
Virtual chassis best practices again this is a document that provides a lot
of the best practices for virtual chassis, we only touched on a couple of
those concepts today. How to configure them, how to cable them, how to
pre-provision; master and backup devices and a lot of different concepts
that are available there. Other resources available just a generic overview
of the Ethernet switches, I talked a lot about the EXC 3200, I talked to a
great extent about the EX 4200 and the virtual chassis today and I have
also talked a little bit about the EX 8200. if you are looking for more
details on interfaces and features and functionality for those various
devises you will see the link there on the Juniper.net site again under the
products and services, under switching EX Series will provide you with all
the information you need from there.
Do we have any questions that are coming through over the phone?
Operator:
No, sir. We have no questions at this time.
Scott Calzia:
Okay. I still see David is typing away madly over here,
answering questions that are coming in online. David any particular one
or two questions that you want to bring out? Or are you busy over there
typing away responding?
David Nguyen:
I think I answered most of it. I guess there is one good
question that people always asked me, what is the difference between the
MX Series and the EX series?
Scott Calzia:
Okay so we had question that came in, what is the
difference between the MX Series and the EX Series? There is quite a
28
few and we actually have some good information on that. Unfortunately I
don’t have the slide up here that I could bring up, so I will try to go through
and describe it. Just talking from a very high level the EX Series is the
Ethernet switch. The MX Series—M is for multiservice type of switch or
what we would call an Ethernet services router. Now as such that is just a
very simple naming, really the key difference between the two is from a
scaling standpoint. Both devices are similar in that they will support
Ethernet interfaces, both EX as well as the MX support gigabit interfaces.
They support 10 gigabit interfaces. The difference is that the MX typically
will scale to much larger forwarding table sizes, typically in the range of
several millions routes, many hundreds of thousands of IP multitask types
of environments and although suitable for enterprise environment typically
has been designed for very highly scalable environments where you would
require a great number of routes or a great number of forwarding entries.
So that really is the fundamental difference between EX and the MX series
is from a scaling standpoint and just depending on what you are scaling
requirements are, will define whether you are going to position the EX or
the MX. Now of course there are some form factor differences. The MX
comes today as a modular type of device and there is a number of
different models available anywhere from a three slot all the way up to a
12 slot device. The EX also has a modular device, the EX 8208 which is
an eight slot. The EX 8216 which is a 16 slot. But the EX also has
standalone devices that are typically suited better for lower density types
of locations such as your wiring closet environments, as well as your
[branch office] locations where your density may not be as great a deploy
as a modular type of platform.
So those are some of the key differences between the EX as well the MX
Series.
David Nguyen:
The next question, [unclear] if he can elaborate on what is
split detection?
Ting Zou:
So split detection is a new feature in the…after 93; basically it
would detect the- It has the new feature called a split. So virtual chassis
can split into two separate virtual chasses and before 93 basically two split
parts were having the same identical configuration which we will cause a
problem. So after 93 there is a new feature called a split detection in the
virtual chassis introduced. So once the virtual chassis is split so only one
29
part of the virtual chassis will be active, the other part will be totally
inactive. So it at least makes the network—50% of network is still up in
the operation. So there is also a [knob] we have left basically if some
customers don’t want this feature, they can enable the no split detection
so the behaviour will be back to before 93. So when the virtual chassis
splits, both parts will have the same identical configuration. So that is split
detection.
Scott Calzia:
Thank you, Ting. So I believe we have run through our hour
and a half. I do—hopefully by doing this I won’t cut off the questions. I
can still see there are a number of questions coming in online. We do
have a poll that I would like everybody to take, for that I am going to go to
what we call the exit lobby. And I am not certain but I hope it won’t cut off
the question and answer, because I do encourage you—if you continue to
have questions and answers, continue to type those in. We will stay
online here for several more minutes and answer those as they continue
to come in. But at this point I want to thank everybody for their time today.
I hope that we had a good presentation and that learned quite a few new
concepts about the EX Series as well as some configuration examples
were helpful. I apologise to those people at the start of the call that had
some difficulty with the audio, but I do want to assure you that you didn’t
miss very much. We did cover back through some of the few things that
you may have missed at the very beginning.
Today’s recording will be available after the call concluded. In addition the
presentation will be available for download as well. So you can certainly
use that and you can listen to it again at a later time. But on behalf of
myself as well Ting and David, I want thank you all today. I appreciate
your time, thank you very much. Do take a few minutes to take the poll
which I am going to bring up here now. Thank you all, have a good day.
Bye-bye.
Operator: That does conclude our conference for today. You may all
disconnect.
30