|
0:00:13
|
Welcome back everybody to InterNetwork Expert CCIE Routing and Switching Advanced Technologies class.
|
|
0:00:19
|
In today's class sessions, we're gonna be talking about multiprotocol label switching
|
|
0:00:23
|
within the scope of the routing and switching lab exam.
|
|
0:00:26
|
We'll see that there's a bunch of topics for MPLS that are going to be outside of the scope
|
|
0:00:30
|
that we're not gonna be discussing today.
|
|
0:00:32
|
Things like MPLS traffic engineering, MPLS Layer 2 VPNs
|
|
0:00:37
|
and then any type of inter AS communication
|
|
0:00:40
|
or doing inter provider MPLS VPNs.
|
|
0:00:44
|
Mainly our discussion today is gonna be focusing on the general logic
|
|
0:00:47
|
of how MPLS can be used as switch packets inside of one single autonomous system.
|
|
0:00:52
|
Then also the Layer 3 VPN topics.
|
|
0:00:56
|
What are the different PE to CE routing protocols that we can use.
|
|
0:01:00
|
Also, we'll look at the virtual routing and forwarding instances
|
|
0:01:03
|
using those for both the VRF light configuration and for the Layer 3 MPLS VPNs.
|
|
0:01:09
|
And how BGP is gonna be used to advertise
|
|
0:01:11
|
both the customer information over the MPLS network.
|
|
0:01:15
|
And then also the label values that are gonna be used for actually switching the traffic.
|
|
0:01:20
|
So, to start here for MPLS,
|
|
0:01:23
|
it is an open standards-based protocol that is defined in RFC 3031.
|
|
0:01:29
|
Originally, this came from Cisco proprietary's feature known as tag switching.
|
|
0:01:34
|
Where most of the terms we'll see are interchangeable
|
|
0:01:36
|
from the older versions of Cisco using the TDP protocol and the tag switching logic.
|
|
0:01:43
|
Where now it's an open standard for MPLS.
|
|
0:01:46
|
And as a part of that,
|
|
0:01:47
|
there is multivendor support for the different protocols that are gonna be used for
|
|
0:01:52
|
both the label distribution and then for the actual forwarding of the traffic.
|
|
0:01:58
|
Now, the name of MPLS itself is mainly gonna be made up of two portions that we'll see.
|
|
0:02:05
|
It's considered a multiprotocol encapsulation
|
|
0:02:09
|
because it can transport different types of payloads.
|
|
0:02:12
|
This includes both Layer 2 and Layer 3 protocols,
|
|
0:02:17
|
where a service provider can do a Layer 2 circuit emulation over MPLS.
|
|
0:02:22
|
Where inside the service provider core, they are running Layer 3 MPLS switching.
|
|
0:02:27
|
When on the network edge between the service provider and the customer,
|
|
0:02:31
|
they can emulate either on Ethernet segment
|
|
0:02:35
|
with features like any transport over MPLS or the virtual private LAN services.
|
|
0:02:41
|
That also point-to-point configurations, like HTLC, PPP frame-relay or ATM.
|
|
0:02:47
|
Where from the end customer's point of view,
|
|
0:02:49
|
they see no difference between a normal Layer 2 private VPN service,
|
|
0:02:55
|
like a point-to-point frame-relay DLCI
|
|
0:02:57
|
But inside the actual service provider network,
|
|
0:02:59
|
this traffic can be switched to over the MPLS network.
|
|
0:03:04
|
Now, again, for our discussion here, we're mainly gonna be focusing on the Layer 3 MPLS configuration.
|
|
0:03:10
|
Which is gonna be used to transport IP version 4.
|
|
0:03:13
|
over the MPLS enabled core.
|
|
0:03:17
|
There are also features available for MPLS to transport IP version 6.
|
|
0:03:23
|
There is an extension that is known as six PE or six Provider Edge
|
|
0:03:28
|
that allows us to run IP version 6 between a provider edge and the customer edge,
|
|
0:03:33
|
then transport this traffic over the IPV 4 enabled MPLS core
|
|
0:03:38
|
without the service provider actually having to run IP version 6 routing.
|
|
0:03:44
|
So, the vast majority the scope of MPLS probably, 80% is gonna be outside of our scope.
|
|
0:03:49
|
We'll kind of narrow it down today to figure out what you actually need to know
|
|
0:03:53
|
particularly for the CCIE routing and switching lab exam.
|
|
0:03:57
|
The second portion of the aim for label switching
|
|
0:04:01
|
is based on how the traffic is routed or switched in the service provider network
|
|
0:04:06
|
where we're remaking a change instead of doing a normal IP version 4 destination-based routing
|
|
0:04:12
|
or Layer 2 circuit switching
|
|
0:04:14
|
like a frame-relay DLCI to a frame-relay DLCI,
|
|
0:04:18
|
and we're replacing this with an MPLS label value
|
|
0:04:22
|
that the devices in the provider network are going to switch
|
|
0:04:26
|
between their interfaces as a locally significant value.
|
|
0:04:31
|
So, it's a similar type of logic as to how an ATM permanent virtual circuit works,
|
|
0:04:35
|
or a frame-relay permanent virtual circuit works,
|
|
0:04:38
|
because the Layer 2 circuit numbers and frame-relay or ATM,
|
|
0:04:43
|
the DLCI numbers, of the VPI VCI
|
|
0:04:46
|
is gonna be the same type of logic as what the MPLS label value is used for.
|
|
0:04:51
|
So, once we actually get into our configurations,
|
|
0:04:54
|
and look at the verification for how the label distribution protocol
|
|
0:04:58
|
does the label to IP prefix binding,
|
|
0:05:02
|
which we call the Forwarding Equivalency Class, or the FEC.
|
|
0:05:06
|
We'll see that these label numbers are only locally significant between two attached devices.
|
|
0:05:12
|
And it's going to allow them to forward traffic anywhere within the provider network
|
|
0:05:16
|
or past the provider network
|
|
0:05:19
|
between different customer sites
|
|
0:05:20
|
without having to null full reachability information about the network.
|
|
0:05:25
|
So, when we actually look at the design advantages of using the MPLS over the normal IP routing design,
|
|
0:05:32
|
the main idea is that inside the MPLS core,
|
|
0:05:35
|
those devices do not necessarily need full reachability information
|
|
0:05:39
|
about what's going on in the overall network.
|
|
0:05:42
|
As long as the routers can agree on these locally significant label values
|
|
0:05:45
|
they can switch traffic to the network edge,
|
|
0:05:48
|
then, the network edge is gonna have specific reachability information about where the traffic is actually supposed to go.
|
|
0:05:54
|
Whether this is going out to a Layer 2 circuit like Ethernet over MPLS,
|
|
0:05:59
|
or going out to a Layer 3 destination like a Layer 3 MPLS VPN that's using IP version 4
|
|
0:06:06
|
as its transport protocol.
|
|
0:06:07
|
Now, the actual MPLS label format itself
|
|
0:06:11
|
is a 4-byte value that is gonna be sitting between the Layer 2 encapsulation
|
|
0:06:16
|
and either the Layer 3 encapsulation or an additional Layer 2 encapsulation.
|
|
0:06:23
|
So, in the case of Ethernet over MPLS,
|
|
0:06:26
|
we would have our normal Layer 2 header that's for the actual transit interface that we're going over.
|
|
0:06:31
|
Followed by the 4-byte MPLS header.
|
|
0:06:34
|
Then, followed by the additional Ethernet header that we're actually tunneling inside of the protocol.
|
|
0:06:40
|
For Layer 3 MPLS configurations,
|
|
0:06:42
|
we would have are normal Layer 2 encapsulation.
|
|
0:06:45
|
Like a Packet over Sonnet, PPP link that's used in the provider network.
|
|
0:06:49
|
Followed by the 4-byte MPLS label,
|
|
0:06:52
|
and then, the actual IP packet payload
|
|
0:06:54
|
that's being transited inside the Layer 3 VPN.
|
|
0:07:01
|
So, the header itself is 4 bytes long.
|
|
0:07:04
|
This is gonna consist of a 20 bit label.
|
|
0:07:07
|
3 bits that are reserved for the class of service that are to be used for QOS markings.
|
|
0:07:13
|
And 7:14 that is gonna define the last label in the stack
|
|
0:07:18
|
that is gonna be used by the provider edge router
|
|
0:07:21
|
in order to figure out that the packet is gonna go down to an end customer who is not running MPLS.
|
|
0:07:26
|
And then, an 8-bit Time To Live value that's similar to the IP Time To Live.
|
|
0:07:31
|
To make sure that we don't end up in infinite loops in the actual data plane
|
|
0:07:34
|
if there's some sort of problem with the actual routing of the traffic through the service provider network.
|
|
0:07:39
|
Now, the actual packet level details about MPLS for the labels,
|
|
0:07:43
|
for label distribution protocol, for BGP.
|
|
0:07:46
|
That type of stuff is really gonna be outside of our scope for the lab exam,
|
|
0:07:50
|
but if you do want more information about this,
|
|
0:07:53
|
generally, the best resource is gonna be the particular RFC's that are defining that individual protocol.
|
|
0:08:00
|
So, we'll see, there's separate ones that define MPLS as a whole.
|
|
0:08:04
|
One that defines the label format,
|
|
0:08:06
|
one that defines how LDP works.
|
|
0:08:09
|
Separate ones that define how BGP is gonna work with MPLS.
|
|
0:08:13
|
So, there's a lot of different individual specifications that go together
|
|
0:08:17
|
in order to form the entire end-to-end MPLS transit network.
|
|
0:08:21
|
Now, the actual operation of MPLS
|
|
0:08:24
|
is gonna be based on our association of a label value
|
|
0:08:28
|
to an IPv4 prefix destination in the network.
|
|
0:08:33
|
And this binding of the label value and IP prefixes known as the Forwarding Equivalency Class, or the FEC.
|
|
0:08:39
|
Now, the FEC is essentially gonna be used to switch the traffic between the router's local interfaces
|
|
0:08:45
|
based on the CEF table that we're now calling the MPLS Label Forwarding Information Base, or the LFIB,
|
|
0:08:52
|
which is essentially our normal CEF FIB
|
|
0:08:55
|
plus an additional label value that's gonna be added on to the encapsulation.
|
|
0:09:00
|
So, we'll see what at our final verifications today,
|
|
0:09:02
|
and the traffic is actually transiting through the MPLS network,
|
|
0:09:06
|
the router is still gonna be using CEF to forward the traffic,
|
|
0:09:08
|
but the difference is that it will pre-calculate what is the label value
|
|
0:09:14
|
that is supposed to go in the Layer 2 header as the packet is actually switched out the interface.
|
|
0:09:19
|
Now, we'll also see, there's a difference in the logic between MPLS switching
|
|
0:09:23
|
versus IP version for routing,
|
|
0:09:26
|
where in IPv4,
|
|
0:09:28
|
we are determining what is the outgoing interface based on the destination address of the IP packet.
|
|
0:09:35
|
So, if a packet comes in that's going to destination 1.2.3.4,
|
|
0:09:39
|
the router is gonna figure out what is my longest match to 1.2.3.4,
|
|
0:09:42
|
and then perform route recursion towards the outgoing interface.
|
|
0:09:47
|
Whereas in MPLS, the outgoing interface is determined based on the incoming label value.
|
|
0:09:53
|
So, this means that if a packet comes in with label number 1,
|
|
0:09:58
|
the router is gonna know that we need to change this to label value 2,
|
|
0:10:01
|
and then, send it out the appropriate interface.
|
|
0:10:05
|
So, in order to do this, the routers in the MPLS transit path
|
|
0:10:08
|
are gonna have to agree on what these locally significant labels are.
|
|
0:10:13
|
So, we'll see the actual label values, that can be used over and over and over on separate interfaces,
|
|
0:10:19
|
because the number itself is only locally significant to the local router,
|
|
0:10:22
|
and then, the device that's attached on the other end of the link.
|
|
0:10:26
|
In the MPLS network, there are two different device roles that were gonna be looking at.
|
|
0:10:30
|
The first is known as the PE router, or the LER,
|
|
0:10:35
|
which is either the Provider Edge Router or the Label Edge Router.
|
|
0:10:40
|
So essentially, they mean the same thing, but the LER is kind of a legacy notation for it
|
|
0:10:46
|
when we're talking about the tag switching.
|
|
0:10:48
|
Most of the time today, this is referred to as the PE router, or the Provider Edge.
|
|
0:10:53
|
So, this is the device on the edge of the provider's network
|
|
0:10:57
|
that is connecting down to the actual customer.
|
|
0:11:00
|
in our particular cases today, this is where we are gonna be running PE to CE routing protocol
|
|
0:11:06
|
to exchange IPv4 routes from the customer to the provider.
|
|
0:11:13
|
Now, in addition to running the...
|
|
0:11:16
|
routing protocols between the provider and the customer,
|
|
0:11:19
|
the PE router is gonna be in charge of adding MPLS labels
|
|
0:11:24
|
to packets in the data plane as they're receiving inbound from the customer.
|
|
0:11:29
|
And this operation is known as the Label Push, or the Label Imposition.
|
|
0:11:34
|
So, we're taking a normal IP packet.
|
|
0:11:37
|
Again, when we're talking about Layer 3 MPLS VPNs,
|
|
0:11:40
|
we're taking a normal Layer 3 IP version 4 packet
|
|
0:11:44
|
as the packet comes in, the router's gonna do a look-up
|
|
0:11:47
|
to figure out what is the label value that is associated with that.
|
|
0:11:50
|
Do the Label Push operation to add the label onto the stack,
|
|
0:11:54
|
and then switch it out another connected interface.
|
|
0:11:59
|
Now, once the traffic is forwarded into the provider core network,
|
|
0:12:03
|
the packet is then received by what's known as the "P router", or the LSR,
|
|
0:12:09
|
where the Provider Router or the Label Switch Router
|
|
0:12:12
|
is inside of the provider network that is not attaching to any customers.
|
|
0:12:18
|
So, from a physical connectivity point of view, the P router is only connected either to other P routers,
|
|
0:12:24
|
or two other PE routers.
|
|
0:12:27
|
The key point being that the provider core routers,
|
|
0:12:31
|
they're only gonna switch the traffic based on the MPLS labels.
|
|
0:12:36
|
They don't necessarily need to have the routing information about the end customers,
|
|
0:12:40
|
or knows any type of information about the Layer 2 circuits the end customers are using
|
|
0:12:45
|
if we're doing some sort of Layer 2 MPLS VPN solution.
|
|
0:12:50
|
Now, we'll also see design-wise that one of the advantages of running MPLS from the service provider's perspective
|
|
0:12:57
|
is that it's gonna reduce the load
|
|
0:12:59
|
in the control plane in the service provider core.
|
|
0:13:04
|
So, we can end up in situations where in the service provider transit network,
|
|
0:13:08
|
they do not need to run BGP with the global Internet table,
|
|
0:13:12
|
and they do not need to know about what the customer's prefixes are
|
|
0:13:15
|
that they're trying to transit traffic between.
|
|
0:13:19
|
Now, these two device roles in the network, the PE router,
|
|
0:13:22
|
which is again the Provider Edge,
|
|
0:13:24
|
and the P router, which is just the Provider router,
|
|
0:13:27
|
they're mainly gonna be performing three different operations.
|
|
0:13:31
|
These are called the Label Push, Swap, and Pop operations.
|
|
0:13:36
|
Label Push is gonna be done by the provider edge,
|
|
0:13:39
|
where we are adding an MPLS label
|
|
0:13:42
|
onto a packet that is received inbound from customer.
|
|
0:13:47
|
So, this is also called the Label Imposition.
|
|
0:13:51
|
The Label Swap operation is generally done by the P router
|
|
0:13:56
|
in the core of the service provider network.
|
|
0:13:59
|
We are receiving a packet inbound that already has a label value assigned.
|
|
0:14:04
|
We are replacing it with a new label value,
|
|
0:14:06
|
and then switch it out another outgoing interface.
|
|
0:14:11
|
So, the Label Swap operation is analogous to what a frame-relay switch
|
|
0:14:15
|
or an ATM switch would be doing in a traditional Layer 2 circuits switch network,
|
|
0:14:21
|
where a frame-relay switch is looking at what is the incoming DLCI value,
|
|
0:14:25
|
and based on that, it's changing the circuit value
|
|
0:14:28
|
in order to be switched out another connected interface.
|
|
0:14:33
|
Once the MPLS packet finally gets to the opposite provider edge router
|
|
0:14:37
|
where it's going to exit the network,
|
|
0:14:40
|
that last hop provider edge router is gonna do the Label Pop operation
|
|
0:14:45
|
that is removing a label from the outgoing packet,
|
|
0:14:48
|
and then sending it on to the end customer.
|
|
0:14:51
|
This is also sometimes called the Label Disposition,
|
|
0:14:54
|
where we are removing the MPLS labels, or the entire MPLS stack
|
|
0:14:58
|
and then, forwarding of out of the MPLS enabled network.
|
|
0:15:03
|
Now, in order for the routers to do the Label Switching,
|
|
0:15:07
|
it means the first off, they're gonna need to agree on what the mappings are between the label numbers,
|
|
0:15:12
|
and the IP prefixes.
|
|
0:15:15
|
So again, this is what we consider the Forwarding Equivalency Class, or the FEC.
|
|
0:15:20
|
Now again, the label values are only locally significant between to attached routers.
|
|
0:15:24
|
So, we don't need on overall routing protocol like we do in OSPF or IS-IS
|
|
0:15:31
|
that knows the full information about the entire topology.
|
|
0:15:35
|
We'll see that the majority of the label distribution protocols
|
|
0:15:39
|
are going to rely on underlying loop prevention mechanisms like IGP
|
|
0:15:46
|
in order to make sure that the underlying network is loop-free,
|
|
0:15:50
|
and that we know about the entire topology to begin with.
|
|
0:15:55
|
So, the first two of these dynamic protocols, the advertise, the label information,
|
|
0:15:59
|
are the legacy Tag Distribution Protocol, or TDP,
|
|
0:16:03
|
and the open standard version of this, which is the Label Distribution Protocol, or LDP.
|
|
0:16:11
|
So, for the vast majority of our configurations today,
|
|
0:16:13
|
we're gonna be looking at the LDP derived labels,
|
|
0:16:18
|
where technically,we could also do this with Resource Reservation Protocol, which is RSVP.
|
|
0:16:23
|
This is used for MPLS traffic engineering or MPLS TE implementations,
|
|
0:16:29
|
and also multi-protocol BGP could technically be used to advertise both the IP prefix and the associated label value.
|
|
0:16:38
|
But the vast majority of the time, if we're not using additional applications like MPLS traffic engineering,
|
|
0:16:43
|
we're simply gonna run the Label Distribution Protocol
|
|
0:16:46
|
on every single interface in the MPLS network that is also running IGP.
|
|
0:16:52
|
Now, LDP itself is specified in a separate RFC that is 3036.
|
|
0:16:59
|
The LDP Specification.
|
|
0:17:01
|
The main things that we care about with LDP
|
|
0:17:04
|
are that the neighbors will be automatically discovered
|
|
0:17:07
|
using UDP multicasts going to the all router multicast of 224.0.0.2
|
|
0:17:13
|
using UDP 646.
|
|
0:17:17
|
And once the neighbors discover each other, then, they are going to establish a TCP session
|
|
0:17:22
|
using the same port value 646
|
|
0:17:25
|
going to their LDP router IDs.
|
|
0:17:30
|
So, we'll see in the operation of this, this is the same type of logic as BGP uses for a peering,
|
|
0:17:36
|
where BGP can change the TCP update source to its loopback interface.
|
|
0:17:40
|
This is the same type logic that Label Distribution Protocol is gonna use by default.
|
|
0:17:47
|
So, the LDP router ID, it's gonna be chosen with the same logic as how the OSPF router ID,
|
|
0:17:53
|
or EIGRP, BGP router ID,
|
|
0:17:56
|
where IOS is gonna look at what is the highest loopback address
|
|
0:18:00
|
that is allocated to router.
|
|
0:18:02
|
If there's no loopback address assigned then, it's gonna be the highest IP address that's assigned on any other interface.
|
|
0:18:10
|
So, in order to establish the LDP adjacency then,
|
|
0:18:14
|
we're assuming in the MPLS transit network that we are already running IGP.
|
|
0:18:21
|
Now, in a real design,
|
|
0:18:22
|
the vast majority the time that IGP is either going to be OSPF or IS-IS,
|
|
0:18:28
|
but technically, it could be any protocol.
|
|
0:18:31
|
It could be EIGRP, or RIP,
|
|
0:18:33
|
it could even be static routing.
|
|
0:18:35
|
As long as we have IGP reachability to all of the different portions of the network,
|
|
0:18:40
|
then, LDP is automatically gonna do our label bindings.
|
|
0:18:46
|
Now, the key point we'll see it from the operation of LDP
|
|
0:18:50
|
is that it is an IGP-based Label Distribution Protocol.
|
|
0:18:55
|
This means that LDP is only going to advertise any interface that is locally enabled for IGP,
|
|
0:19:02
|
and any IGP learned prefixes.
|
|
0:19:06
|
So, when we look in the routing table and say Show IP Route OSPF,
|
|
0:19:10
|
and look at the Show IP Protocols and see what are the local interfaces that are running OSPF,
|
|
0:19:14
|
those are the values that are gonna be advertised in the Forwarding Equivalency Classes.
|
|
0:19:22
|
We'll also see that the label values are originated on a hop by hop basis
|
|
0:19:27
|
since they are only locally significant between
|
|
0:19:30
|
the two connected routers over the link.
|
|
0:19:33
|
Or, in the case of a multipoint segment like three routers over a LAN,
|
|
0:19:36
|
the label values would then be significant to all three of them.
|
|
0:19:40
|
The actual configuration of MPLS is very straightforward.
|
|
0:19:44
|
There's only basically one command in order to enable the process,
|
|
0:19:47
|
which is MPLS IP at the interface level,
|
|
0:19:52
|
which is automatically going to enable either LDP or TDP
|
|
0:19:56
|
depending on what the default is for the MPLS Label Protocol in a global config.
|
|
0:20:03
|
Now, the reason that this is significant is that different IOS versions use different defaults for this.
|
|
0:20:08
|
Some of the older versions use TDP as the default Label Protocol.
|
|
0:20:13
|
Whereas the newer ones should automatically default to LDP.
|
|
0:20:19
|
Since the actual protocol format for TDP and LDP is not compatible,
|
|
0:20:24
|
they use different UDP port numbers for discovery, they use different TCP port numbers for the actual adjacency.
|
|
0:20:31
|
It means that the connected devices do need to agree on whether they're gonna run the LDP or TDP.
|
|
0:20:39
|
Now, we can technically have designs where the network is mixed between some portions running TDP
|
|
0:20:44
|
and some portions running LDP.
|
|
0:20:46
|
Because again, it is only locally significant on a link by link basis.
|
|
0:20:51
|
There's really no reason why you would want to do that design.
|
|
0:20:54
|
Generally, you're just gona use label distribution protocol on all of your IGP enabled interfaces.
|
|
0:20:59
|
But you could technically have a mix of LDP and TDP if you wanted to.
|
|
0:21:07
|
Once the LDP process is enabled,
|
|
0:21:10
|
we look at the Show MPLS LDP Iinterfaces, that's gonna tell us what links are actually running the protocol locally.
|
|
0:21:17
|
Show MPLS LDP Neighbors is gonna show the adjacency status between the connected devices.
|
|
0:21:22
|
This is gonna make sure that we are actually establishing the TCP peerring
|
|
0:21:28
|
which would then allow us to actually exchange the label values.
|
|
0:21:31
|
So, the equivalent of the show IP route for MPLS is gonna be the Show MPLS Forwarding Table.
|
|
0:21:38
|
So, this is the Label Forwarding Information Base or the LFIB,
|
|
0:21:42
|
which is the combination of the label value and the IP prefix.
|
|
0:21:48
|
So, the Show MPLS Forwarding Table, that's what's verifying the Forwarding Equivalency Class or the FEC.
|
|
0:21:54
|
Now, the final verification to figure out how the router is actually encapsulating the traffic,
|
|
0:21:59
|
would still be based on the CEF table.
|
|
0:22:02
|
So, we Show IP CEF or Show IP CEF Internal,
|
|
0:22:05
|
that's gonna show us on the router
|
|
0:22:06
|
what are the particular adjacencies that are associated with a particular destination
|
|
0:22:11
|
and then what's the label value that's gonna be used as the packet is encapsulated out the interface.
|
|
0:22:19
|
So, in general, you shouldn't really need to verify the CEF table.
|
|
0:22:22
|
Because looking at the Show MPLS Forwarding Table is essentially gonna give as the same information.
|
|
0:22:30
|
Then lastly, we'll see to, actually, look at the traffic flow
|
|
0:22:34
|
since the routers are now going to be switching the traffic based on the MPLS labels.
|
|
0:22:39
|
Any debugging of the actual data plane would be with the debug MPLS packets now
|
|
0:22:44
|
as opposed to the debug IP packets.
|
|
0:22:48
|
We'll see later when we get into some more advanced examples of this.
|
|
0:22:52
|
Running MPLS in the service provider core
|
|
0:22:54
|
is also gonna have us have a loss of visibility as to what types of traffic are actually going over the network.
|
|
0:23:03
|
So, when we look at quality of service with MPLS or any type of filtering with MPLS,
|
|
0:23:09
|
it gets more difficult to classify what are the actual flows
|
|
0:23:13
|
that are going over the service provider network.
|
|
0:23:16
|
Because now, they are classifying the packets based on the MPLS header
|
|
0:23:19
|
not based on the IP packet that is inside of the payload.
|
|
0:23:24
|
So, this would then mean, if we wanted to do some sort of firewall filtering or just basic access list filtering,
|
|
0:23:30
|
that's not going to apply if the packets are MPLS as they are forwarding out the interface.
|
|
0:23:35
|
Or if we are trying to do some sort of quality of service,
|
|
0:23:38
|
let's say, we wanna put our voice over IP traffic into a priority queue,
|
|
0:23:42
|
if we try to classify the packets based on the real-time protocol header,
|
|
0:23:48
|
and that is a sub-encapsulation of UDP,
|
|
0:23:51
|
the routers not gonna be able to see that because the classifier is working now on the MPLS label
|
|
0:23:56
|
not based on the IP header.
|
|
0:24:00
|
So, there's some kind of hacks on the process. We'll see that how we deal with quality of service with MPLS,
|
|
0:24:06
|
which is mainly gonna be based on a translation between the IP type of service
|
|
0:24:13
|
that could be based on the DSCP value or the IP precedence
|
|
0:24:17
|
or any manual classification that we're doing.
|
|
0:24:21
|
And the classification in the Layer 2 MPLS label,
|
|
0:24:24
|
which is known as the MPLS experimental bits or essentially the MPLS class of service.
|
|
0:24:32
|
Now, the topology that we're gonna be using for today's examples
|
|
0:24:36
|
is a different logical setup that we've been using up to this point.
|
|
0:24:40
|
Where we have routers 1 through 6 that are made up of the MPLS service provider core.
|
|
0:24:47
|
Routers 1, 2 and 3, these are gonna be considered as the P routers.
|
|
0:24:55
|
Because they are attached only to other P routers and other PE routers.
|
|
0:25:03
|
Which in this case, are routers 4, 5 and 6.
|
|
0:25:07
|
Ultimately, we'll see at the end of the day that this means that routers 1, 2 and 3,
|
|
0:25:12
|
they're not gonna need to know reachability information
|
|
0:25:14
|
about anything that's going on in the EIGRP domain or the RIP domain,
|
|
0:25:20
|
the OSPF process 100 or the BGP AS 254, that's running on BB2.
|
|
0:25:28
|
As long as in the service provider core of the MPLS network,
|
|
0:25:33
|
we have label values that are associated with all of the provider edge routers.
|
|
0:25:39
|
Then ultimately, a packet can be received in on router 4
|
|
0:25:43
|
and switched out to either router 6 or router 5
|
|
0:25:47
|
based on the label value and not based on the actual IP destination.
|
|
0:25:54
|
So, let's look at the command line here and the first thing that we're gonna do
|
|
0:25:58
|
is configure just the basic MPLS network between routers 1 through 6.
|
|
0:26:04
|
Look at how we're doing the label allocation with LDP
|
|
0:26:08
|
and then look at some of the caveats that we could potentially run into
|
|
0:26:10
|
when we're trying to establish our label distribution protocol adjacencies.
|
|
0:26:16
|
So, first, let's start on router 1
|
|
0:26:18
|
and let's look at what's going on in the IGP table to begin with.
|
|
0:26:23
|
So if we look at the Show IP Route,
|
|
0:26:26
|
right now, we are running OSPF in the service provider core.
|
|
0:26:31
|
And router 1 through router 6, they're advertising loopback interfaces that are 10.0.1.1, 10.0.2.2 through 10.0.6.6.
|
|
0:26:40
|
All the AS /32 host routes.
|
|
0:26:44
|
We'll see that there are some caveats of the MPLS design
|
|
0:26:48
|
that dictate you have to use a /32 loopback
|
|
0:26:53
|
for the value that's gonna be used for the multiprotocol BGP peering,
|
|
0:26:58
|
that is used to advertise the costumer route between the different PE routers.
|
|
0:27:05
|
So, in general, in the provider network, all of the router should have a /32 loopback
|
|
0:27:10
|
that's gonna be used for the actual label switching to that particular router.
|
|
0:27:15
|
Now, in some service provider designs,
|
|
0:27:18
|
the loopback itself will be the only address that's actually
|
|
0:27:22
|
can be referenced to that router from other devices,
|
|
0:27:25
|
where on the transit links between the routers, they could be unnumbered links
|
|
0:27:29
|
or they could be using link local address space or private addressing.
|
|
0:27:34
|
Because we really only care about getting traffic to that particular node in the network,
|
|
0:27:40
|
which we're denoting based on the loopback
|
|
0:27:43
|
and the actual transit traffic that is going between the customers
|
|
0:27:46
|
is never gonna be sent to the provider's transit links itself.
|
|
0:27:52
|
So, if we were to look at that topology here,
|
|
0:27:54
|
from the perspective of one of the customers, let's say, inside EIGRP AS 10,
|
|
0:28:00
|
they would not need to know the reachability information about the transit link between routers 1 and 3.
|
|
0:28:05
|
Or between 1 and 2, or 2 and 3.
|
|
0:28:10
|
As long as their traffic could be received in and then switched out to the other exit point of the provider network,
|
|
0:28:19
|
then the actual customer in EIGRP AS 10 is not gonna need to know specific reachability information about the provider.
|
|
0:28:27
|
So, the key point being here that these routes that are installed on router 1,
|
|
0:28:32
|
these are only locally significant to the provider.
|
|
0:28:35
|
These do not have to be advertised into the global BGP table
|
|
0:28:38
|
as long as the internal IGP of the provider allows us to get reachability to all of the routers loopbacks
|
|
0:28:45
|
that's wrote what we really care about to start.
|
|
0:28:51
|
Now, since LDP is an IGP-based label distribution protocol,
|
|
0:28:56
|
it means that once LDP is enabled on the per link basis,
|
|
0:29:02
|
then we should automatically see label bindings for all of these routes that we see in the routing table.
|
|
0:29:08
|
It's gonna be any of our connected interfaces that are running IGP.
|
|
0:29:12
|
Plus the actual routes that are being learned from OSPF.
|
|
0:29:16
|
So, from router 1's perspective, if we were to look at the Show IP Protocols,
|
|
0:29:22
|
we see that OSPF is running on any interface that starts with 10.0.
|
|
0:29:28
|
So, if we were to look at the Show IP Route Connected,
|
|
0:29:33
|
this would then mean when router 1 runs Label Distribution Protocol or LDP,
|
|
0:29:39
|
there should be bindings for these 4 connected interfaces
|
|
0:29:43
|
in addition to any route that already show up as OSPF in the routing table.
|
|
0:29:50
|
So, again, the key point with the actual label distribution,
|
|
0:29:53
|
is that it is locally significant on a hop by hop basis..
|
|
0:29:59
|
So, although router three is gonna be running label distribution protocol,
|
|
0:30:02
|
router 3 is not the router that does the label binding for its own local loopback.
|
|
0:30:08
|
The label number that's associated with router 3's loopback is gonna change on a hop-by-hop basis
|
|
0:30:13
|
as the different routers negotiate that particular value.
|
|
0:30:20
|
Now, again, the actual configuration is really straightforward with this.
|
|
0:30:24
|
First, we need to make sure that CEF is on.
|
|
0:30:27
|
Which normally, this should be the default value that IP CEF is on in global config.
|
|
0:30:32
|
If the IOS is already using LDP as the default label distribution protocol,
|
|
0:30:37
|
we don't necessarily need to specify the second command,
|
|
0:30:40
|
but in reality, there's no reason that we would not want to do that.
|
|
0:30:45
|
So, just to make sure that there's no discrepancies between the different IOS versions,
|
|
0:30:49
|
it would be a good idea to make sure that CEF is on,
|
|
0:30:53
|
and that the MPLS label protocol is LDP.
|
|
0:30:58
|
Now, for this particular version on router 1,
|
|
0:31:01
|
it says that it is using TDP by default.
|
|
0:31:05
|
So, if I did not specify this globally,
|
|
0:31:08
|
or at each individual link level,
|
|
0:31:11
|
then, the routers would not be able to establish the adjacency.
|
|
0:31:16
|
So, it's kind of like how .1Q and ISL works.
|
|
0:31:19
|
They're technically doing the same thing at the end result,
|
|
0:31:23
|
which is to add a VLAN number 4 encapsulation.
|
|
0:31:26
|
But if we're running ISL on one side and .1Q on the other side, it's not gonna work.
|
|
0:31:29
|
Because the protocols are using different formats.
|
|
0:31:33
|
Same thing with LDP and TDP.
|
|
0:31:34
|
At the end of the day, they're really doing the same thing,
|
|
0:31:36
|
which is associating a label number to an IP prefix,
|
|
0:31:41
|
but if the two routers are not running the same label protocol on a connected link,
|
|
0:31:45
|
then, they're not going to be able to exchange the label numbers.
|
|
0:31:53
|
So next, on all of the connected interfaces,
|
|
0:31:55
|
we're going to enable the LDP process.
|
|
0:31:59
|
So, on router 1, we simply need to go to these connected links,
|
|
0:32:03
|
and at the interface level, say, MPLS IP.
|
|
0:32:08
|
We don't need to enable this on the loopback,
|
|
0:32:10
|
because there's no actual LDP adjacency that occurs on that link.
|
|
0:32:16
|
Now, we'll see that the loopback is going to get a labelled binding
|
|
0:32:20
|
because it's already advertised into IGP.
|
|
0:32:25
|
As long as the interface is running OSPF, then,
|
|
0:32:27
|
the router is gonna automatically advertise a labelled value for it.
|
|
0:32:33
|
So next, on router 1, let's look at the Show IP Route Connected.
|
|
0:32:37
|
And we have three connected Ethernet links.
|
|
0:32:40
|
One is going to router 2, one is going to router 3, one is going to router 6.
|
|
0:32:44
|
So, at these link levels, we'll say, simply MPLS IP.
|
|
0:32:52
|
The link to router 3, and then also, the link to router 6.
|
|
0:33:00
|
So, pretty straightforward configuration. Basically, only two commands so far.
|
|
0:33:06
|
We'll do the same thing on router 2, if we Show IP Route Connected.
|
|
0:33:10
|
I'll say, MPLS label...
|
|
0:33:14
|
protocol is LDP globally.
|
|
0:33:17
|
Then, at the link levels, MPLS IP.
|
|
0:33:22
|
And if we look at some of the other MPLS sub-options,
|
|
0:33:26
|
we could also specify these MPLS label protocol here at the link level,
|
|
0:33:31
|
where the...
|
|
0:33:33
|
specific one of the interface is gonna override what is in global configuration.
|
|
0:33:38
|
So, if we wanted to run LDP for the vast majority of our interfaces,
|
|
0:33:42
|
we could specify that globally,
|
|
0:33:44
|
then, if we wanted to override this on a per-link basis, we could either set it to TDP,
|
|
0:33:49
|
or set it to both in order to allow both particular adjacencies.
|
|
0:33:55
|
But again, the vast majority of the time, you wouldn't want to run TDP
|
|
0:33:58
|
because it's considered the legacy protocol.
|
|
0:34:02
|
There's some other basic features that TDP doesn't support like authentication
|
|
0:34:07
|
that you generally would want in your MPLS network.
|
|
0:34:11
|
So, we'll see, the features that are really specific to LDP
|
|
0:34:16
|
are not that involved configuration-wise.
|
|
0:34:20
|
The...
|
|
0:34:21
|
configuration that's gonna be difficult
|
|
0:34:25
|
is the end logic that we're trying to piece together when we're building the MPLS layer 3 VPN.
|
|
0:34:30
|
So, once we get to that point, we'll break down the individual steps
|
|
0:34:34
|
of how we create the VRF,
|
|
0:34:36
|
how we define what's gonna be the route distinguisher, what's gonna be the route target,
|
|
0:34:40
|
and then the interaction between the BGP MPLS network,
|
|
0:34:44
|
and then, the customer edge network, which is gonna be running some sort of
|
|
0:34:48
|
VRF aware routing process.
|
|
0:34:54
|
So now, on all six of these routers, I do have LDP pre-configured.
|
|
0:34:58
|
If we look at the Show MPLS Interfaces,
|
|
0:35:02
|
we see on router 2, it says that LDP is enabled on my three local links.
|
|
0:35:07
|
It says that "Tunneling mode is disabled."
|
|
0:35:09
|
This means that we are not running Resource Reservation Protocol, or RSVP.
|
|
0:35:16
|
So, this doesn't necessarily mean that we're not running an MPLS tunnel.
|
|
0:35:20
|
It simply means that we're not running MPLS traffic engineering tunnels.
|
|
0:35:25
|
Where again, that's generally gonna be outside of the scope of routing and switching
|
|
0:35:28
|
so we're not really gonna get any into that details of that.
|
|
0:35:33
|
Next, if we were to look at the Show MPLS LDP Neighbors,
|
|
0:35:39
|
from router 2's perspective,
|
|
0:35:40
|
we should now see an adjacency with all of the other connected routers
|
|
0:35:44
|
that are also running the LDP protocol.
|
|
0:35:47
|
So, if we were to look back at the topology here from router 2's perspective,
|
|
0:35:50
|
it should ideally have an adjacency with router 1,
|
|
0:35:53
|
with router 3, and with router 4.
|
|
0:35:58
|
This again is gonna assume that these four devices have already established the IGP adjacencies,
|
|
0:36:05
|
and exchanged the internal topology through the normal IGP routing protocol.
|
|
0:36:10
|
So again, whether this is OSPF, IS-IS, RIP, EIGRP, it technically doesn't matter,
|
|
0:36:15
|
but in the vast majority of real design cases, it's generally gonna be just either OSPF or IS-IS.
|
|
0:36:25
|
So now, on router 2, if we look at the details of the Show MPLS LDP Neighbors,
|
|
0:36:30
|
it says, "First, I have a peer that is going to 10.0.4.4."
|
|
0:36:35
|
This is the remote peer's LDP identifier,
|
|
0:36:39
|
or essentially, their LDP router ID,
|
|
0:36:42
|
where my LDP router ID is 10.0.2.2.
|
|
0:36:47
|
So, by default, this value was coming from the loopback interface that has the highest IP address assigned.
|
|
0:36:55
|
So, just like BGP or OSPF,
|
|
0:36:58
|
the devices are not gonna be able to establish adjacency if they do not have unique identifiers.
|
|
0:37:06
|
Once they choose the identifier,
|
|
0:37:08
|
that is then gonna be used as the default TCP connect source.
|
|
0:37:15
|
That's the actual value that's used to generate the packets between the two neighbors.
|
|
0:37:19
|
So, we can see here, between router 4 and router 2,
|
|
0:37:22
|
it says, "The TCP connection used is using TCP port 646.
|
|
0:37:27
|
It's coming from router 4's loopback going to router 2's loopback."
|
|
0:37:30
|
This would then imply, if I did not already have reachability to 10.0.4.4
|
|
0:37:39
|
as I were to source packets from my own loopback.
|
|
0:37:44
|
If I were not able to reach router 4's loopback, then, I would not be able to establish the LDP adjacency.
|
|
0:37:52
|
Now, it should be fairly obvious whether we're having a transport problem here
|
|
0:37:57
|
between the two neighbors because we can simply look again at the Show MPLS LDP Neighbors.
|
|
0:38:02
|
It's gonna show what the TCP connection source is supposed to be between the two neighbors.
|
|
0:38:08
|
Also, if we were to look at the Debug MPLS LDP Transport Events,
|
|
0:38:16
|
this is gonna show us any potential problems is the actual adjacency establishment.
|
|
0:38:23
|
So, it's telling us where we are receiving hellos from,
|
|
0:38:27
|
where we are sending hellos out to,
|
|
0:38:30
|
we can see that the hellos are using the multicast destination 224.0.0.2,
|
|
0:38:36
|
which is reserved for all routers.
|
|
0:38:39
|
If we were to look at the Debug IP Packet Detail,
|
|
0:38:45
|
LDP is an IP-based protocol,
|
|
0:38:48
|
where it's using UDP port 646
|
|
0:38:52
|
for the discovery of the neighbors.
|
|
0:38:55
|
So again, the discovery is going to that multicast address 224.0.0.2.
|
|
0:39:00
|
Then, if we look at the debug again,
|
|
0:39:04
|
we should see that there is a TCP connection
|
|
0:39:11
|
that's going between the neighbors.
|
|
0:39:12
|
So, right now, we're not actually exchanging any label values through TCP,
|
|
0:39:17
|
because the network is already converged.
|
|
0:39:19
|
But we will have a periodic keepalive just like we do for our BGP peerings.
|
|
0:39:25
|
We can see between router 4 and router 2,
|
|
0:39:28
|
router 4 in this case is the TCP client,
|
|
0:39:31
|
where router 4 is sending packets to the destination port 646.
|
|
0:39:36
|
When router 2 replies, router 2 is the TCP server,
|
|
0:39:41
|
and the packets are coming from 646 going back to the loopback of router 4.
|
|
0:39:49
|
So, this is then gonna imply a couple things about the actual LDP adjacency.
|
|
0:39:53
|
If for some reason, first off, I didn't have a route between the loopback addresses,
|
|
0:39:58
|
then, we're not gonna be able to know where to send the TCP packets.
|
|
0:40:02
|
It also implies we would need to make sure that TCP port 646
|
|
0:40:07
|
and UDP port 646 going to the all router multicast
|
|
0:40:13
|
is able to transit between the routers.
|
|
0:40:16
|
So, we would need to make sure there's no Layer 3 or Layer 4 filtering like with access lists.
|
|
0:40:22
|
Also, if we were running this over a non-broadcast media like a frame-relay multipoint interface.
|
|
0:40:29
|
We would need to make sure that we have the Pseudo Broadcast support
|
|
0:40:33
|
in order to send the multicast to 224.0.0.2.
|
|
0:40:39
|
But in the vast majority of cases inside the service provider network,
|
|
0:40:43
|
the links are gonna be point-to-point, either point-to-point Ethernet, or point-to-point Packet over Sonnet.
|
|
0:40:48
|
So, we should not have any type of Layer 3 to Layer 2 resolution problem.
|
|
0:40:52
|
With Ethernet, we know that we can use the ARP process
|
|
0:40:55
|
to figure out where we're supposed to send those multicasts to.
|
|
0:40:59
|
In the case of Packet over Sonnet, that's a point-to-point encapsulation that's running PPP.
|
|
0:41:04
|
So, we don't need to worry about any type of Layer 2 addressing.
|
|
0:41:10
|
So again, assuming that there's nothing wrong with the underlying transport.
|
|
0:41:13
|
Once LDP is enabled, all of the label advertisements should happen automatically.
|
|
0:41:21
|
Now, if there is a problem,
|
|
0:41:24
|
let's say theoretically that router 4 were not to advertise its loopback to IGP.
|
|
0:41:30
|
So, right now, in the loopback of router 4,
|
|
0:41:34
|
at the interface level, I simply have the IP OSPF command
|
|
0:41:37
|
to put this into area zero.
|
|
0:41:39
|
So, if I were to go to loopback zero and remove...
|
|
0:41:44
|
this advertisement into IGP,
|
|
0:41:50
|
then, from router 2, on the link level to router 4,
|
|
0:41:54
|
I'm going to say, No MPLS IP.
|
|
0:42:00
|
We can see, that's removing the adjacency between router 2 and router 4.
|
|
0:42:06
|
Then, we're gonna look at the Debug MPLS LDP Transport Events,
|
|
0:42:13
|
and re-enable MPLS on the interface. So, simply MPLS IP.
|
|
0:42:23
|
So, we should now see that we're receiving
|
|
0:42:26
|
the UDP hellos coming in from router 4,
|
|
0:42:30
|
and also, router 2 is locally generating these.
|
|
0:42:33
|
But if we're to look at the routing table
|
|
0:42:36
|
to see where the reachability is to that particular address,
|
|
0:42:42
|
so if we Show IP Route for 10.0.4.4,
|
|
0:42:47
|
okay, we could see, router 2 does not have a route to that.
|
|
0:42:52
|
If we then look at the Show MPLS LDP Neighbors,
|
|
0:43:00
|
we see that we still have the adjacencies with router 1 and router 3,
|
|
0:43:05
|
because I still have the routes to their loopbacks.
|
|
0:43:08
|
But we no longer have the reachability information to router 4.
|
|
0:43:15
|
So, to cut down on the output a little bit here, I'm just gonna shut those other interfaces down temporarily.
|
|
0:43:20
|
So, on router 2,
|
|
0:43:22
|
I'm gonna disable Fast Ethernet 0/0.12,
|
|
0:43:24
|
and Fast Ethernet 0/0.23.
|
|
0:43:32
|
So, on interface f0/0.12, we'll shut this down.
|
|
0:43:36
|
And then, also the .23.
|
|
0:43:43
|
Now, again, if we look at the Debug MPLS LDP Transport Events,
|
|
0:43:56
|
and also, if we were to look at the Debug IP Packet Detail,
|
|
0:44:01
|
we should see that router 2 is attempting to start the TCP session
|
|
0:44:07
|
going over to router 4,
|
|
0:44:12
|
but the packet that is gonna go out to router 4
|
|
0:44:20
|
is gonna be unroutable.
|
|
0:44:21
|
Now, we can also see that message that's going for router 1 and router 3's loopbacks.
|
|
0:44:25
|
So, the key with LDP
|
|
0:44:29
|
is that it is dynamic similar to how BGP is with the control plane
|
|
0:44:34
|
that as long as we have some route between the neighbor's transport addresses,
|
|
0:44:39
|
which is gonna be the loopback by default.
|
|
0:44:41
|
Then, we should be able to establish the adjacency.
|
|
0:44:46
|
Now, this would also mean
|
|
0:44:48
|
that if there are multiple physical link between two routers running LDP,
|
|
0:44:52
|
they're not going to establish multiple adjacencies.
|
|
0:44:56
|
It's only one adjacency between the two routers,
|
|
0:44:59
|
because the label values that we advertise, they're gonna be
|
|
0:45:02
|
locally significant separately to those connected interfaces.
|
|
0:45:07
|
So, it doesn't matter if I use the same label value on Fast Ethernet 0/0 versus Fast Ethernet 0/1,
|
|
0:45:13
|
because those numbers are only locally significant to the router that's on the other end.
|
|
0:45:20
|
Now, we should actually see this error
|
|
0:45:23
|
on router 2, this may have to do with the version
|
|
0:45:27
|
that I'm running here. On router 2, let's look at the Show Version Include IOS.
|
|
0:45:34
|
Routers 1, 2, 3, in my particular topology, these are 2600XMs.
|
|
0:45:39
|
So, the IOS version that we are running at this point,
|
|
0:45:43
|
the 12.4 Mainline Advance Enterprise Services
|
|
0:45:45
|
does not support MPLS on the 2600s.
|
|
0:45:49
|
So, for today's demos, I actually have the down grade for 12.3 Mainline Advance Enterprise Services,
|
|
0:45:55
|
where any of the ISRs, the 1800, 1900, 2800, or above,
|
|
0:46:01
|
those are gonna support MPLS in the 12.4T and later tracks.
|
|
0:46:07
|
So, on router 4, 5, and 6,
|
|
0:46:09
|
if we look at the Show Version include the IOS,
|
|
0:46:12
|
this is running 12.4T Advance Enterprise Services.
|
|
0:46:17
|
But for the MPLS core, when you're actually testing out these configurations,
|
|
0:46:22
|
pretty much all of these you could do on lower level platforms like 2600 or 3600s.
|
|
0:46:27
|
As long as you use a couple IOS versions in the older trains,
|
|
0:46:32
|
like the 12.4 Mainline as opposed to the 12.4T.
|
|
0:46:36
|
Also, you can do a bunch of this either Dynamets of GNS 3,
|
|
0:46:41
|
because the 3600s and the 3700s are gonna support the MPLS features for the virtualization.
|
|
0:46:50
|
So, if you were to test this out in Dynamets, you can run 12.4T on the 3700s,
|
|
0:46:56
|
and then, essentially, you'll be able to see all of the features that you need to test out.
|
|
0:47:01
|
Now, when we look at all the configuration once it's done,
|
|
0:47:05
|
the devices in the core, router 1, 2, and 3, since these are P routers only,
|
|
0:47:11
|
they are not gonna need any other configuration
|
|
0:47:14
|
than just LDP enabled on the interface level.
|
|
0:47:18
|
They're not gonna be running multi-protocol BGP,
|
|
0:47:20
|
they're not gonna need to know about any of the routes that are coming from the customers,
|
|
0:47:24
|
because they are only going to be switching the traffic based on the MPLS labels.
|
|
0:47:30
|
So, let's go back to...
|
|
0:47:34
|
router 4 here. And what I'm gonna do...
|
|
0:47:40
|
on router 4 is temporarily remove OSPF on the link between 2 and 4 as well.
|
|
0:47:47
|
So, we'll say, No IP OSPF 200 Area Zero.
|
|
0:47:52
|
Then, likewise on router 4, we'll look at the Debug MPLS LDP Transport Events.
|
|
0:47:58
|
You'll see that different IOS versions have a little bit different outputs
|
|
0:48:01
|
for some of these show commands and debug commands,
|
|
0:48:04
|
but it's ultimately gonna be the same logic.
|
|
0:48:07
|
So, what I'm looking for here is that there should be a message that says,
|
|
0:48:10
|
"I don't have a route to that particular neighbor."
|
|
0:48:17
|
And I'm wondering if in Advance Enterprise Services, the debug doesn't show this.
|
|
0:48:22
|
Let's try...
|
|
0:48:24
|
Let's try a different one. Let's say, Debug MPLS...
|
|
0:48:29
|
LDP...
|
|
0:48:39
|
Session...
|
|
0:48:42
|
No, it should be... It should be the Transport Events. Let's try Transport Connections.
|
|
0:48:48
|
And Transport Events. Basically, I'm looking for the error message that router 4 is gonna say,
|
|
0:48:53
|
"I don't have a route, there it is."
|
|
0:48:55
|
Okay, it says, "I don't have a route to the peer 10.0.2.2.
|
|
0:48:58
|
So, there's no way that I can set up the TCP connection."
|
|
0:49:02
|
So again, the key point here
|
|
0:49:05
|
is that by default,
|
|
0:49:07
|
the router's gonna look at its connected interfaces and pick the highest loopback address as the LDP router ID.
|
|
0:49:14
|
The LDP router ID is then gonna be used as the connect source
|
|
0:49:19
|
for every interface that's running the protocol.
|
|
0:49:22
|
Now, you can technically change this. If I were to go to the link level Fast Ethernet 0/0.24.
|
|
0:49:29
|
And say, The MPLS LDP discovery transport address,
|
|
0:49:37
|
we could change this to a different IP address number or to a different interface.
|
|
0:49:42
|
Typically, the only case that you would need to do this in
|
|
0:49:45
|
is that if you had overlapping loopback addresses,
|
|
0:49:49
|
because you're trying to do some sort of any cast implementation,
|
|
0:49:54
|
and we'll talk about this when we get to multicast.
|
|
0:49:56
|
The any cast run a good point that can be used for
|
|
0:49:59
|
redundancy inside the network.
|
|
0:50:03
|
But we could technically have a design where router 2 and router 4
|
|
0:50:08
|
are sharing the same loopback address.
|
|
0:50:12
|
And if this interface, let's say it's 10.0.255.255.
|
|
0:50:20
|
So, this address, this is a /32.
|
|
0:50:23
|
And it's being advertised by both router 2 and router 4 as their connected interfaces.
|
|
0:50:28
|
So, when packets are sent to that, depending on where they're coming from physically in the topology,
|
|
0:50:34
|
it's either gonna be received by router 2 or 4
|
|
0:50:37
|
depending on who is physically closer.
|
|
0:50:40
|
But then, the design issue you can run into
|
|
0:50:43
|
is that the IGPs, BGP, and LDP
|
|
0:50:48
|
would choose that highest loopback address as the router ID,
|
|
0:50:53
|
then, we're not gonna be able to establish the adjacencies.
|
|
0:50:55
|
Because if 2 and 4 are using the same value as the transport address,
|
|
0:51:00
|
it doesn't make sense that router 4 would be able to send a packet from this address
|
|
0:51:04
|
that's going to this address.
|
|
0:51:08
|
So, in that very specific design case, you would wanna go to the interface level
|
|
0:51:12
|
and specify that I wanna change what the transport address is.
|
|
0:51:17
|
But again, under normal cases, you don't need to do this.
|
|
0:51:19
|
As long as LDP is on all of the IGP interfaces,
|
|
0:51:24
|
and likewise, IGP is on all of your connected interfaces,
|
|
0:51:29
|
then, the router should automatically figure out what the transport address is supposed to be,
|
|
0:51:33
|
and then automatically establish the TCP connection.
|
|
0:51:38
|
So now, on router 4, if I go to the loopback,
|
|
0:51:41
|
and say, IP OSPF 200 Area Zero,
|
|
0:51:45
|
and again, let's look at the Debug MPLS LDP Transport Events.
|
|
0:51:51
|
Then, at the LAN interface, I'll re-enable OSPF.
|
|
0:51:56
|
We should see, once the OSPF adjacency is there
|
|
0:52:01
|
that we do have a route to router 2's loopback,
|
|
0:52:05
|
now, we can open the connection to them.
|
|
0:52:08
|
It says, "Opening an LDP connection is coming from my loopback going to router 2's loopback."
|
|
0:52:14
|
Then, eventually,
|
|
0:52:17
|
we should get a log message that the LDP neighbor is up.
|
|
0:52:21
|
So, even if you're not debugging the low level LDP information, you should still see this log
|
|
0:52:28
|
that's similar to like the BGP peer coming up, or the OSPF neighbor coming up.
|
|
0:52:35
|
Once the adjacency is up, we can look at the Show MPLS LDP Neighbors.
|
|
0:52:39
|
It's gonna tell us the particular address
|
|
0:52:42
|
that we have the TCP connection for.
|
|
0:52:44
|
And also, any links on the other side
|
|
0:52:48
|
that that peer is running LDP on.
|
|
0:52:52
|
So now, from router 4's perspective, it knows that router 2 is running LDP
|
|
0:52:57
|
on the link that has the 24.2 address
|
|
0:53:00
|
and it's loopback zero.
|
|
0:53:03
|
Now again, on router 2, I didn't actually configure LDP on the loopback.
|
|
0:53:08
|
This is implied based on the fact that the loopback is in OSPF.
|
|
0:53:14
|
Now, once I go to those other interfaces, the link to router 1, and the link to router 3,
|
|
0:53:20
|
and bring these interfaces back up,
|
|
0:53:27
|
we see that OSPF is now adjacent between router 1 and router 2,
|
|
0:53:31
|
between router 2 and router 3.
|
|
0:53:33
|
We should then see, they automatically form the LDP adjacencies.
|
|
0:53:38
|
Now, on router 4, when we look at the change in the Show MPLS LDP Neighbor,
|
|
0:53:43
|
it now knows that router 2 is running LDP on these additional interfaces as well.
|
|
0:53:50
|
So, if the routers do have multiple physical links between each other,
|
|
0:53:54
|
they're automatically gonna figure this out based on the addresses
|
|
0:53:57
|
that the remote peer is binding to LDP.
|
|
0:54:00
|
So, they will not establish a separate TCP session on a per-link basis.
|
|
0:54:04
|
It's just gonna be just one globally between the two neighbors.
|
|
0:54:09
|
So now that we figured out who the neighbors are supposed to be,
|
|
0:54:12
|
we discovered them by using our UDP multicasts going to port 646,
|
|
0:54:16
|
going to 224.0.02, which again is the all router multicast.
|
|
0:54:22
|
We automatically establish the TCP session based on our LDP router ID.
|
|
0:54:27
|
Now, we do the actual label advertisement.
|
|
0:54:31
|
We could look at the low level debug for this,
|
|
0:54:33
|
but pretty much, there's not any information that you can need from
|
|
0:54:37
|
the actual label allocation debugging.
|
|
0:54:41
|
You should be able to assume that if you're correct interfaces are in IGP,
|
|
0:54:47
|
then, they will get allocations of label numbers.
|
|
0:54:51
|
So, from router 4's perspective,
|
|
0:54:53
|
router 4 should have the IGP routes
|
|
0:54:56
|
to the transit interfaces between the other routers.
|
|
0:55:02
|
It should also have the IGP routes to all of their loopbacks.
|
|
0:55:07
|
And then, router 4 has two connected interfaces. It has its own Fast Ethernet 0/0.24.
|
|
0:55:13
|
And it has its own loopback.
|
|
0:55:16
|
This means that router 4 is going to be advertising
|
|
0:55:20
|
label bindings to its own two connected interfaces
|
|
0:55:24
|
and for all of these IGP learned routes.
|
|
0:55:28
|
So, if there was another router beyond router 4,
|
|
0:55:32
|
let's say, router 7, we were also running LDP,
|
|
0:55:36
|
it means that router 4 would be doing label bindings towards router 7
|
|
0:55:40
|
for all of those routes that are installed in the routing table as OSPF
|
|
0:55:44
|
plus the connected interfaces.
|
|
0:55:48
|
The end result of this, if we look at the Show MPLS Forwarding Table on router 4
|
|
0:55:57
|
is that we should see label values
|
|
0:56:00
|
associated with all IGP routes that are multiple hops away.
|
|
0:56:05
|
And the pop label...
|
|
0:56:09
|
for any IGP routes that are directly connected to our connected neighbors.
|
|
0:56:16
|
So, in this particular case, it says we're going to pop the labels
|
|
0:56:19
|
for the loopback of router 2,
|
|
0:56:22
|
the link between router 1 and router 2,
|
|
0:56:25
|
and the link between router 2 and router 3.
|
|
0:56:30
|
So, from router 4's perspective,
|
|
0:56:33
|
these three interfaces that are saying, "Pop label 4",
|
|
0:56:36
|
or specifically, the three routes that it's saying, "Pop label 4."
|
|
0:56:40
|
The loopback of 2,
|
|
0:56:42
|
Fast Ethernet 0/0.12 of router 2,
|
|
0:56:45
|
and Fast Ethernet 0/0.23.
|
|
0:56:49
|
Now, the reason why that these do not have decimal values
|
|
0:56:53
|
for the outgoing labels
|
|
0:56:57
|
is a feature that's known as the Pen Ultimate Hop Popping,
|
|
0:57:01
|
or the PHP process.
|
|
0:57:05
|
Now, the Pen Ultimate Hop simply means, the next to last hop.
|
|
0:57:11
|
So, without this feature enabled,
|
|
0:57:14
|
normally, what would happen is the provider edge router,
|
|
0:57:18
|
or any traffic that is going down to the end customer,
|
|
0:57:20
|
it would have to do two separate lookups.
|
|
0:57:23
|
It would have to do a lookup on the MPLS label that's received inbound,
|
|
0:57:27
|
remove the MPLS label, and then do a lookup on the normal IP prefix.
|
|
0:57:33
|
So, the Pen Ultimate Hop Popping process, or PHP
|
|
0:57:37
|
is basically an optimization of the labelled lookup
|
|
0:57:41
|
that says, "The device that is the next to last hop
|
|
0:57:47
|
is automatically going to remove the topmost label in the stack
|
|
0:57:51
|
before it is sent out to that connected neighbor."
|
|
0:57:56
|
And the way that this is specifically accomplished
|
|
0:57:59
|
is that through LDP,
|
|
0:58:01
|
the router is going to be advertising the implicit null label value,
|
|
0:58:06
|
for any of its connected interfaces.
|
|
0:58:12
|
So, from our topology's point of view,
|
|
0:58:14
|
router 2 is saying, "I have three connected interfaces. They're my loopback, and my two LAN interfaces.
|
|
0:58:19
|
Actually, my three LAN interfaces."
|
|
0:58:22
|
Since router 2 has an LDP adjacency with router 4,
|
|
0:58:27
|
it's going to advertise these these label values
|
|
0:58:31
|
as implicit null.
|
|
0:58:33
|
It's telling router 4 that these destinations, these are directly connected to me.
|
|
0:58:39
|
So, if router 4 were to send a ping
|
|
0:58:41
|
to the interface address of router 2,
|
|
0:58:44
|
that would not be sent as an MPLS packet. It would be sent as a normal IP packet.
|
|
0:58:50
|
However, if router 4 were sending a ping to router 1's link to router 3,
|
|
0:58:55
|
or the loopback of router 6,
|
|
0:58:57
|
those packet would be MPLS encapsulated,
|
|
0:59:00
|
because they are multiple hops away.
|
|
0:59:05
|
Now, in either case, whether the router is doing the implicit null, or whether it is not doing the implicit null,
|
|
0:59:11
|
which is considered the explicit null advertisement,
|
|
0:59:15
|
the end result is gonna be the same.
|
|
0:59:17
|
There should be no difference in the connectivity.
|
|
0:59:20
|
It's simply an optimization of the underlying label lookup.
|
|
0:59:25
|
So, anytime we look at the Show MPLS Forwarding Table,
|
|
0:59:29
|
for any destination that is multiple hops away,
|
|
0:59:33
|
we should see that there's a decimal value in the outgoing label.
|
|
0:59:39
|
For any destination that we are the next to last hop,
|
|
0:59:44
|
so, we are connected to router 2,
|
|
0:59:46
|
router 2 is connected to these three interfaces.
|
|
0:59:51
|
We should see the pop label.
|
|
0:59:55
|
What we should not see is the No Label output.
|
|
0:59:59
|
If it says, No Label, it means the traffic is being sent on a non-MPLS enabled interface.
|
|
1:00:09
|
Now, on router 6,
|
|
1:00:11
|
right now, I have it pre-configured to run EIGRP on the link to backbone 1.
|
|
1:00:17
|
But this link here, serial 0/0.101,
|
|
1:00:20
|
this is not enabled to LDP.
|
|
1:00:24
|
So, it's a normal IP interface, it's not running MPLS.
|
|
1:00:27
|
On router 6, if we were to look at the...
|
|
1:00:31
|
Show MPLS Interfaces,
|
|
1:00:36
|
it says, "There's only one link that I'm running MPLS on.
|
|
1:00:40
|
It's my Fast Ethernet that's going over to router 1."
|
|
1:00:43
|
This means that when we look in the routing table,
|
|
1:00:47
|
the only interface that can now have label values associated with it
|
|
1:00:53
|
is Fast Ethernet 0/0.16.
|
|
1:00:58
|
Because this is the one that's actually running LDP.
|
|
1:01:01
|
For the routes that I'm currently learning on of the serial link,
|
|
1:01:05
|
since this is not an MPLS enabled interface,
|
|
1:01:09
|
it means that any packets that are going out that link, I need to remove all MPLS labels.
|
|
1:01:16
|
And the way that the router denotes this, if we look at the Show MPLS Forwarding Table
|
|
1:01:21
|
is that these...
|
|
1:01:23
|
will have no label value.
|
|
1:01:28
|
So, there's a fundamental difference here between whether the router is saying to pop the label,
|
|
1:01:33
|
or to send No Label.
|
|
1:01:36
|
In certain versions, you'll see this No Label as untagged.
|
|
1:01:40
|
It basically means that whatever the link is here,
|
|
1:01:42
|
this is a non-MPLS interface.
|
|
1:01:47
|
For any interface that is running MPLS, we should either see a decimal value,
|
|
1:01:52
|
like here, we see label 22, 18, and 23,
|
|
1:01:55
|
or we should see pop label,
|
|
1:01:58
|
which means that we are the next to last hop.
|
|
1:02:01
|
Some versions here instead of pop label, it'll say, IMP null for implicit null.
|
|
1:02:08
|
So, if we were to actually test this out, let's say that from router 6's perspective,
|
|
1:02:13
|
we do a traceroute to the loopback of router 1.
|
|
1:02:20
|
Since we are the next to last hop here,
|
|
1:02:23
|
this is not getting an MPLS label.
|
|
1:02:28
|
However, if we were to send the traffic multiple hops away, let's say we send it to router 2's loopback,
|
|
1:02:34
|
we see that there is a label value
|
|
1:02:37
|
when we're forwarding the traffic out that interface.
|
|
1:02:40
|
So, by default, the MPLS label is only gonna be used for destinations that are multiple hops away
|
|
1:02:45
|
on an interface that's actually running MPLS.
|
|
1:02:49
|
For any interface that does not have LDP enabled,
|
|
1:02:52
|
we're gonna see that as No Label.
|
|
1:02:56
|
For any destinations that are only one hop away, we should see Hop Label.
|
