[AUDIO LOGO]
So now that we have VPLS up and running for customer A,
we're now going to configure Ethernet over MPLS for customer
B. Before we do that though, let's go ahead
and jump in and take a look at some of the details of how
Ethernet over MPLS functions.
Then in the next video, we'll be jumping into the command line
and getting it up and running, but let's
start off with those details.
Ethernet over MPLS is really the most popular form of--
remember the Virtual Private Wire Service or AToM,
Any transport over MPLS.
And one of the things it brings to the table
is it's going to remove unneeded headers from the Ethernet
frame, while it's in transit.
So in other words, while it's going through the MPLS core.
We're not going to need things such as the preamble
or the start of frame limiter or the SFD.
It's also not going to need the Frame Check
Sequence or the FCS.
Now, of course, these will be added back
on when it's sent out as plain Ethernet on the other side.
Also, when we're operating in Ethernet port mode,
all of the VLAN information is going to be transmitted.
Now, that said, the VLAN tag can be overwritten on the egress PE
if you have a need or desire to do so.
Now, these Ethernet Virtual Circuits or EVCs,
define the following aspects of attachment
and virtual circuits.
First is frame matching based on either one or more VLAN tags.
Number two, the optional VLAN tag manipulation.
That's what we were just talking about earlier
with being able to override it.
Of course, we're going to be handling
traffic forwarding with the EVC and any additional services
such as QoS.
Something else, of course, it's important
in any service provider environment is redundancy.
We have several different ways to provide this redundancy
in Ethernet over MPLS.
First, we could just do redundant remote PE routers.
That would certainly provide redundancy.
We could also have redundant attachment circuits going out
to the CE.
And we could have redundant Pseudowires.
Now, something to keep in mind that if the path between the PE
routers--
so of course, this means we're referring
to the service provider core.
If that can be repaired using the IGP,
well, honestly, it's never going to look like this went down.
The IGP, be it ISS or OSPF, will converge
so quickly that the original Pseudowire will simply
be rerouted.
Again, it won't even look like it went down.
It'll just start following a different path.
Now, if the failure actually prevents that repair--
in other words, there's no way to repair
the primary Pseudowire--
then it would switch to the backup Pseudowire.
Now, redundancy can be implemented
either one way or two way.
With one way, only one side has redundancy.
Normally, that's not something we're going to want.
Although, it would be possible that maybe
a customer wants redundancy, maybe at their headquarters
but maybe, not at a remote site.
But more commonly, we're going to go ahead and do
two way, where there's two PEs on both sides.
Now if we do this, we're going to end up
with a full mesh of Pseudowires.
We're going to end up with only one Pseudowire being active.
All the rest of them will be standby.
This also requires Multi--Chassis Link Aggregation
Group or MC-LAG.
And the protocol used for that is InterChassis Communication
Protocol or ICCP.
This is what's used to actually form the redundancy group
so the devices know which Pseudowires are primary,
which ones are backup, which ones are active,
which ones are standby.
So ICCP is the protocol that makes the Multi-Chassis Link
Aggregation Group possible.
So in this video, we just jumped in
and got a little bit more detailed information about how
Ethernet over MPLS operates.
And we got to see a little bit about how redundancy
can work in this environment.
Now, of course, though, it's time
to jump onto the command line and get this up
and running for customer B in our environment.
And that's exactly what we're going to do next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.