1
00:00:00,000 --> 00:00:02,832
[MUSIC PLAYING]

2
00:00:02,832 --> 00:00:08,029

3
00:00:08,029 --> 00:00:12,590
So the first issue we want to
address with Layer 3 VPNs is,

4
00:00:12,590 --> 00:00:16,430
how do we keep those customer
routes that could, again,

5
00:00:16,430 --> 00:00:19,880
be overlapping-- and
very commonly will be--

6
00:00:19,880 --> 00:00:23,970
how do we keep those
separate on the PE router?

7
00:00:23,970 --> 00:00:25,850
And the answer to
that is we're going

8
00:00:25,850 --> 00:00:30,560
to use Virtual Routers
and Forwarders, or VRFs.

9
00:00:30,560 --> 00:00:33,560
So in this video, we're
going to jump in and take

10
00:00:33,560 --> 00:00:37,910
a little bit of a detailed look
at how the VRFs actually work,

11
00:00:37,910 --> 00:00:41,570
and how they keep that
traffic separate on the PE.

12
00:00:41,570 --> 00:00:45,590
Let's go ahead and get started.

13
00:00:45,590 --> 00:00:47,590
So given that one
of our concerns

14
00:00:47,590 --> 00:00:52,720
is keeping the customers
separate, this could--

15
00:00:52,720 --> 00:00:55,780
keyword, could--
have been done with

16
00:00:55,780 --> 00:00:57,680
a couple different methods.

17
00:00:57,680 --> 00:01:00,790
For example, we could
have used, possibly,

18
00:01:00,790 --> 00:01:04,690
ACLs, policy-based routing.

19
00:01:04,690 --> 00:01:07,540
We could use route filtering.

20
00:01:07,540 --> 00:01:09,530
Here's an expensive option.

21
00:01:09,530 --> 00:01:15,260
How about a separate physical
PE for each customer?

22
00:01:15,260 --> 00:01:18,030
The problem with all
of these solutions,

23
00:01:18,030 --> 00:01:23,420
they would work just fine if
our only concern was keeping

24
00:01:23,420 --> 00:01:25,670
the customers' routes separate.

25
00:01:25,670 --> 00:01:30,380
But none of these addressed
the issue of the overlapping

26
00:01:30,380 --> 00:01:31,820
IP addressing.

27
00:01:31,820 --> 00:01:34,850
And keeping in mind that
this is the customers'

28
00:01:34,850 --> 00:01:36,590
internal routing.

29
00:01:36,590 --> 00:01:42,350
A lot of these customers will be
using RFC 1918 addresses inside

30
00:01:42,350 --> 00:01:43,680
of their network.

31
00:01:43,680 --> 00:01:47,210
Therefore, the chance of
there being a network overlap

32
00:01:47,210 --> 00:01:50,390
between hundreds or
thousands of customers

33
00:01:50,390 --> 00:01:52,680
is actually pretty high.

34
00:01:52,680 --> 00:01:54,410
So this is definitely
something we

35
00:01:54,410 --> 00:01:59,120
have to take into
consideration in our solution.

36
00:01:59,120 --> 00:02:01,990
So again the problems
here, aside from the one

37
00:02:01,990 --> 00:02:04,640
I just mentioned, which would
be the bottom choice here,

38
00:02:04,640 --> 00:02:06,130
we already talked
about this one--

39
00:02:06,130 --> 00:02:09,910
that it's impossible to account
for those overlapping IP

40
00:02:09,910 --> 00:02:10,930
addresses.

41
00:02:10,930 --> 00:02:13,180
But even more than
that, this would

42
00:02:13,180 --> 00:02:16,240
be very prone to human error.

43
00:02:16,240 --> 00:02:21,340
Somebody has to do the ACLs,
or the policy-based routing,

44
00:02:21,340 --> 00:02:23,440
or the route filtering.

45
00:02:23,440 --> 00:02:27,100
This would be the responsibility
of, most likely, a human.

46
00:02:27,100 --> 00:02:29,480
With automation today,
there, of course,

47
00:02:29,480 --> 00:02:31,010
could be exceptions to that.

48
00:02:31,010 --> 00:02:33,460
But either way,
this is something

49
00:02:33,460 --> 00:02:35,860
that could be very,
very prone to error.

50
00:02:35,860 --> 00:02:40,790
Also, it would be difficult
to separate routing protocols.

51
00:02:40,790 --> 00:02:43,100
Now again, this may
not be a huge concern,

52
00:02:43,100 --> 00:02:46,790
particularly if we're only
supporting BGP, for example.

53
00:02:46,790 --> 00:02:50,720
But either way, these
aren't great solutions.

54
00:02:50,720 --> 00:02:54,730
So what we do instead is we have
a Virtual Router and Forwarder.

55
00:02:54,730 --> 00:02:59,020
So what this effectively does
is creates a different PE

56
00:02:59,020 --> 00:03:02,170
for each customer, which,
if we think about it,

57
00:03:02,170 --> 00:03:03,890
is really the best solution.

58
00:03:03,890 --> 00:03:06,923
If it's a separate
router, well then

59
00:03:06,923 --> 00:03:09,340
we don't have to worry about
routing tables intermingling,

60
00:03:09,340 --> 00:03:13,360
or overlapping address space, or
ACLs, or policy-based routing,

61
00:03:13,360 --> 00:03:14,930
or any of that.

62
00:03:14,930 --> 00:03:18,700
The problem is, a physical
router for every customer

63
00:03:18,700 --> 00:03:20,360
would be very expensive.

64
00:03:20,360 --> 00:03:22,960
So instead of doing
that, we're going

65
00:03:22,960 --> 00:03:26,210
to do a separate routing table.

66
00:03:26,210 --> 00:03:29,590
So essentially, it's
a virtual router.

67
00:03:29,590 --> 00:03:32,170
Remember, at the end
of the day, a router

68
00:03:32,170 --> 00:03:37,600
really is nothing more than
interfaces, a routing table,

69
00:03:37,600 --> 00:03:40,810
and generally some way to
populate that routing table,

70
00:03:40,810 --> 00:03:41,560
i.e.

71
00:03:41,560 --> 00:03:43,460
a routing protocol.

72
00:03:43,460 --> 00:03:46,060
So all we're really doing
at this point is creating

73
00:03:46,060 --> 00:03:47,800
a separate routing table.

74
00:03:47,800 --> 00:03:51,550
The management plane itself
will still be shared.

75
00:03:51,550 --> 00:03:53,950
In other words, when you
log into this device,

76
00:03:53,950 --> 00:03:55,570
you do a show run.

77
00:03:55,570 --> 00:03:58,690
You're going to see all of
the configuration for all

78
00:03:58,690 --> 00:03:59,860
of the VRFs.

79
00:03:59,860 --> 00:04:02,410
We're not separating
management at all.

80
00:04:02,410 --> 00:04:05,050
We're separating the
forwarding of traffic

81
00:04:05,050 --> 00:04:07,900
and the maintenance
of the routing tables.

82
00:04:07,900 --> 00:04:11,590
Now, like we said, the router
is just a routing table

83
00:04:11,590 --> 00:04:13,730
with interfaces assigned to it.

84
00:04:13,730 --> 00:04:16,720
So again, we have
to assign interfaces

85
00:04:16,720 --> 00:04:18,740
to the routing table.

86
00:04:18,740 --> 00:04:21,850
We also mentioned that there's
usually a routing protocol

87
00:04:21,850 --> 00:04:24,410
to populate said routing table.

88
00:04:24,410 --> 00:04:27,400
And what we're going to be doing
is running those separately

89
00:04:27,400 --> 00:04:29,440
for every VRF.

90
00:04:29,440 --> 00:04:32,150
That way, they get
populated on their own.

91
00:04:32,150 --> 00:04:34,600
They're going to have their
own neighbors, and so on,

92
00:04:34,600 --> 00:04:37,310
with the various
routing protocols.

93
00:04:37,310 --> 00:04:39,970
So let's take a look at a
diagram here real quickly,

94
00:04:39,970 --> 00:04:43,790
and see how this fits
into the big picture.

95
00:04:43,790 --> 00:04:46,030
So this is just a
conceptual drawing

96
00:04:46,030 --> 00:04:48,970
that we'll use during our
discussion of these MPLS

97
00:04:48,970 --> 00:04:49,960
concepts.

98
00:04:49,960 --> 00:04:52,480
It's not related to
any of our topologies,

99
00:04:52,480 --> 00:04:54,220
just so we're clear.

100
00:04:54,220 --> 00:04:56,980
Now, in this drawing,
we have two customers,

101
00:04:56,980 --> 00:04:59,650
Customer A at the top, and
Customer B at the bottom.

102
00:04:59,650 --> 00:05:03,730
And of course, we have our
MPLS core here in the middle.

103
00:05:03,730 --> 00:05:08,740
Where the VRFs are going to
be created is here on the PEs.

104
00:05:08,740 --> 00:05:13,630
So each one of these little
circles here represents a VRF.

105
00:05:13,630 --> 00:05:18,700
So we would have a VRF for
Customer A on the PEs connected

106
00:05:18,700 --> 00:05:25,150
to Customer A, and a VRF for
Customer B on the PEs connected

107
00:05:25,150 --> 00:05:29,440
to Customer B This, of course,
would keep the routes totally

108
00:05:29,440 --> 00:05:32,500
separate, whether they're
overlapping address space,

109
00:05:32,500 --> 00:05:35,090
which, as you can see
in our example here,

110
00:05:35,090 --> 00:05:36,850
we are definitely
going to be dealing

111
00:05:36,850 --> 00:05:39,430
with overlapping address space.

112
00:05:39,430 --> 00:05:42,250
We purposefully put
both customers in here

113
00:05:42,250 --> 00:05:45,170
with exactly the
same addressing.

114
00:05:45,170 --> 00:05:46,990
So we're going to be
dealing with keeping

115
00:05:46,990 --> 00:05:51,250
the routes separated, as well
as dealing with this overlapping

116
00:05:51,250 --> 00:05:52,670
address space.

117
00:05:52,670 --> 00:05:55,690
Again, this is not
a problem so far.

118
00:05:55,690 --> 00:05:58,780
Because of our VRFs, we're
going to receive the routes

119
00:05:58,780 --> 00:05:59,860
from the customer.

120
00:05:59,860 --> 00:06:03,400
And those routes are going to
go into the respective VRFs

121
00:06:03,400 --> 00:06:05,530
on each PE.

122
00:06:05,530 --> 00:06:10,450
So for now, the customer
routes have been handled.

123
00:06:10,450 --> 00:06:16,150
So in this video, we talked
about using VRFs on the PEs

124
00:06:16,150 --> 00:06:21,130
to keep the customer traffic
and routes completely separate.

125
00:06:21,130 --> 00:06:24,670
This way, we don't have to
involve things like ACLs,

126
00:06:24,670 --> 00:06:27,500
or policy-based routing,
or anything like that.

127
00:06:27,500 --> 00:06:30,640
These are acting like
physical routers,

128
00:06:30,640 --> 00:06:33,010
in that they're completely
and totally isolating

129
00:06:33,010 --> 00:06:34,150
the customers.

130
00:06:34,150 --> 00:06:35,410
But they're not.

131
00:06:35,410 --> 00:06:38,680
They're virtual routers
that are just really

132
00:06:38,680 --> 00:06:42,490
instances of the routing
table with assigned interfaces

133
00:06:42,490 --> 00:06:46,030
and protocols on each PE.

134
00:06:46,030 --> 00:06:50,680
Now that the customer routes are
on the PE routers in the VRFs,

135
00:06:50,680 --> 00:06:52,390
we now have to
worry about getting

136
00:06:52,390 --> 00:06:55,420
those routes to the other PEs.

137
00:06:55,420 --> 00:06:57,130
That's going to
be our next step.

138
00:06:57,130 --> 00:06:59,390
And that's what we're
going to talk about next.

139
00:06:59,390 --> 00:07:02,740
Until then, I hope this has
been informative for you,

140
00:07:02,740 --> 00:07:05,850
and I'd like to thank
you for viewing.

141
00:07:05,850 --> 00:07:09,000