WEBVTT

1
00:00.000 --> 00:03.840
The control plane continues to be a big part of SD-WAN.

2
00:03.840 --> 00:09.890
We've got a lot of information to share among all of these different WAN edges

3
00:09.890 --> 00:10.160
and even

4
00:10.160 --> 00:13.840
among some of our other control and management nodes.

5
00:13.840 --> 00:17.400
Well this information is going to be shared with a protocol we refer to as the

6
00:17.400 --> 00:18.440
overly management

7
00:18.440 --> 00:20.440
protocol or OMP.

8
00:20.440 --> 00:25.870
OMP is sort of like a routing protocol, except it's also sort of not like a

9
00:25.870 --> 00:27.960
routing protocol.

10
00:27.960 --> 00:33.420
And by the way, this is Cisco proprietary because it was developed by the Vept
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:27.960 --> 00:33.420
And by the way, this is Cisco proprietary because it was developed by the Vept

11
00:33.420 --> 00:34.360
ella, the company

12
00:34.360 --> 00:39.780
they acquired, and it's really only used within the world of SD-WAN, at least

13
00:39.780 --> 00:40.360
at the time

14
00:40.360 --> 00:42.280
of this recording.

15
00:42.280 --> 00:45.480
We don't see it used on networks otherwise.

16
00:45.480 --> 00:47.000
So what exactly is OMP?

17
00:47.000 --> 00:49.680
Well I said it's sort of like a routing protocol.

18
00:49.680 --> 00:54.800
I prefer to think of it as an information carrying protocol.

19
00:54.800 --> 00:58.440
And some of that information can be routes, but it can also carry a lot of

20
00:58.440 --> 00:59.560
other information.

21
00:59.560 --> 01:06.100
In fact, this might sound familiar to you because if we've ever studied BGP, BG
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

21
00:59.560 --> 01:06.100
In fact, this might sound familiar to you because if we've ever studied BGP, BG

22
01:06.100 --> 01:07.000
P is also

23
01:07.000 --> 01:08.720
an information carrying protocol.

24
01:08.720 --> 01:14.200
I can carry a lot of different things besides just IP4 routes and IPv6 routes.

25
01:14.200 --> 01:19.600
I can carry MAC address information if I want to and BGP because it's not built

26
01:19.600 --> 01:20.520
strictly

27
01:20.520 --> 01:25.680
for IPv4 routing, whereas OSPF and BG or EIGRP, they were developed

28
01:25.680 --> 01:27.400
specifically and only

29
01:27.400 --> 01:31.670
to carry IPv4 routes, which is why they had to come out with a new version to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

29
01:27.400 --> 01:31.670
to carry IPv4 routes, which is why they had to come out with a new version to

30
01:31.670 --> 01:33.000
carry IPv6

31
01:33.000 --> 01:36.200
routes because they couldn't carry them natively.

32
01:36.200 --> 01:41.760
So even then, they built them to be only carrying IPv6 routes.

33
01:41.760 --> 01:46.120
So kind of an interesting thing and a nuance, a difference between a true

34
01:46.120 --> 01:47.160
routing protocol

35
01:47.160 --> 01:54.120
like OSPF and EIGRP and an information carrying protocol like OMP and BGP.

36
01:54.120 --> 01:58.360
In fact, more and more, I would refer to OMP as very BGP-like.

37
01:58.360 --> 02:03.400
There's a lot of BGP-like behaviors with how OMP operates.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

37
01:58.360 --> 02:03.400
There's a lot of BGP-like behaviors with how OMP operates.

38
02:03.400 --> 02:09.520
For example, another similarity is that it uses TCP connections.

39
02:09.520 --> 02:15.180
Most routing protocols, IGPs especially, don't use TCP, they use multicast to

40
02:15.180 --> 02:15.760
find their

41
02:15.760 --> 02:18.440
neighbors and they have to be directly attached.

42
02:18.440 --> 02:23.750
TCP implies that I can have long range connections, which is important in a WAN

43
02:23.750 --> 02:25.160
circuit space because

44
02:25.160 --> 02:29.920
I need to connect across a layer 3 environment, which is my WAN circuits.

45
02:29.920 --> 02:35.060
So I form a TCP connection knowing what the IP address is that I'm connecting
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
02:29.920 --> 02:35.060
So I form a TCP connection knowing what the IP address is that I'm connecting

46
02:35.060 --> 02:35.640
to.

47
02:35.640 --> 02:44.360
Furthermore, our V-Smart is going to operate as a route reflector.

48
02:44.360 --> 02:51.360
Our reflectors in BGP allow us to not have a full mesh of adjacencies and

49
02:51.360 --> 02:53.000
neighborships.

50
02:53.000 --> 02:59.550
So I don't need to have all of my WAN edge devices appear with all of the other

51
02:59.550 --> 03:00.160
WAN edge
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

51
02:59.550 --> 03:00.160
WAN edge

52
03:00.160 --> 03:01.440
devices.

53
03:01.440 --> 03:07.110
So instead, what we find is we've got a bunch of WAN edges down here and these

54
03:07.110 --> 03:07.920
WAN edges

55
03:07.920 --> 03:12.600
are all trying to communicate to one another and form tunnels.

56
03:12.600 --> 03:17.730
But the question is, how do I take a subnet and advertise this subnet to the

57
03:17.730 --> 03:18.400
rest of the

58
03:18.400 --> 03:19.400
network?

59
03:19.400 --> 03:26.580
Well, what I do is I send it up here to the V-Smart and this advertisement is

60
03:26.580 --> 03:27.640
going to make

61
03:27.640 --> 03:33.110
it so that I don't have to advertise it to the dozens or hundreds or thousands
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

61
03:27.640 --> 03:33.110
it so that I don't have to advertise it to the dozens or hundreds or thousands

62
03:33.110 --> 03:34.160
of other

63
03:34.160 --> 03:35.160
WAN edge routers.

64
03:35.160 --> 03:40.400
Instead, I advertise it just to my V-Smart and the V-Smart pushes it down.

65
03:40.400 --> 03:45.130
And this is that route reflector type of behavior because again, it prevents me

66
03:45.130 --> 03:45.960
from having a full

67
03:45.960 --> 03:47.600
mesh of adjacencies.

68
03:47.600 --> 03:52.810
A bunch of EIG, RP routers all shared a space they would all be neighbors with

69
03:52.810 --> 03:53.740
one another

70
03:53.740 --> 03:59.320
and that's not perfectly ideal, especially not when we're talking about massive

71
03:59.320 --> 03:59.640
scaling.

72
03:59.640 --> 04:02.470
And one of the other important parts in all of this and again, it comes back to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

72
03:59.640 --> 04:02.470
And one of the other important parts in all of this and again, it comes back to

73
04:02.470 --> 04:02.920
the fact

74
04:02.920 --> 04:07.700
that it's an information carrying protocol is the fact that we're going to

75
04:07.700 --> 04:09.200
carry attributes.

76
04:09.200 --> 04:14.740
There's a lot of different attributes we can carry and so we might say that,

77
04:14.740 --> 04:15.200
hey, you

78
04:15.200 --> 04:21.600
can get to subnet A this way via this WAN circuit, but keep in mind, we've got

79
04:21.600 --> 04:22.300
this other

80
04:22.300 --> 04:26.160
WAN circuit over here.

81
04:26.160 --> 04:31.120
And maybe for a particular application, I actually want to go this way.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

81
04:26.160 --> 04:31.120
And maybe for a particular application, I actually want to go this way.

82
04:31.120 --> 04:35.940
Maybe this is my voice over IP packets and I want to send it via MPLS rather

83
04:35.940 --> 04:36.480
than the

84
04:36.480 --> 04:37.720
internet.

85
04:37.720 --> 04:42.110
And so deciding on application-based forwarding, this is going to rely heavily

86
04:42.110 --> 04:43.680
on more information

87
04:43.680 --> 04:47.360
than just a subnet ID and how far away it is.

88
04:47.360 --> 04:52.080
I'm going to use these attributes to make those types of forwarding decisions.

89
04:52.080 --> 04:57.160
Now OMP has several different route types.

90
04:57.160 --> 05:01.240
So when it's advertising, it's not just a single update like most of our
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

90
04:57.160 --> 05:01.240
So when it's advertising, it's not just a single update like most of our

91
05:01.240 --> 05:02.680
routing protocols.

92
05:02.680 --> 05:05.920
And just say, here's your update of a bunch of information.

93
05:05.920 --> 05:09.400
And said we have three different types of routes that we share.

94
05:09.400 --> 05:13.120
First of all, are simply OMP routes.

95
05:13.120 --> 05:21.010
OMP routes are going to carry these subnets to advertise site networks so we

96
05:21.010 --> 05:21.880
know how to

97
05:21.880 --> 05:25.280
route between our end user subnets.

98
05:25.280 --> 05:29.620
That's kind of one of the biggest parts of SD-WAN is being able to route from

99
05:29.620 --> 05:30.880
subnet A to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

99
05:29.620 --> 05:30.880
subnet A to

100
05:30.880 --> 05:34.240
subnet B through this SD-WAN environment.

101
05:34.240 --> 05:37.000
And so that's how we're going to have this.

102
05:37.000 --> 05:45.880
It also is going to map these local subnets to our T-locks.

103
05:45.880 --> 05:49.150
And that's going to be part of the glue that holds all this together because

104
05:49.150 --> 05:49.760
then we can

105
05:49.760 --> 05:54.600
look at a second route type which is a T-lock route.

106
05:54.600 --> 05:59.760
A T-lock route tells us how to get to the T-locks.

107
05:59.760 --> 06:03.940
So it's great that I know, for example, that if I want to get to subnet A, that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

107
05:59.760 --> 06:03.940
So it's great that I know, for example, that if I want to get to subnet A, that

108
06:03.940 --> 06:04.460
I should

109
06:04.460 --> 06:09.440
send to this specific T-lock, we'll just call it T-lock A.

110
06:09.440 --> 06:12.830
So we're trying to send to this T-lock, but remember, a T-lock doesn't have an

111
06:12.830 --> 06:13.600
IP address.

112
06:13.600 --> 06:15.560
So how do I know where that is?

113
06:15.560 --> 06:17.560
Well that's what the T-lock route does.

114
06:17.560 --> 06:25.640
It maps a T-lock to the proper IP address for connectivity.

115
06:25.640 --> 06:32.460
This allows me to build the tunnel to the remote T-lock and then I can then use
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

115
06:25.640 --> 06:32.460
This allows me to build the tunnel to the remote T-lock and then I can then use

116
06:32.460 --> 06:33.220
the information

117
06:33.220 --> 06:37.240
I get from the OMP routes so know how to connect the actual subnets.

118
06:37.240 --> 06:42.380
Now the last type is a service route and the service route is going to allow me

119
06:42.380 --> 06:43.280
to do

120
06:43.280 --> 06:45.680
things like service chaining.

121
06:45.680 --> 06:53.520
Service chaining enables me as an admin to force traffic to go a particular way

122
06:53.520 --> 06:53.960
.

123
06:53.960 --> 06:57.940
Maybe I want the traffic to go through a particular device in order to get ins

124
06:57.940 --> 06:59.060
pected before sending

125
06:59.060 --> 07:01.000
out to the rest of the network.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

125
06:59.060 --> 07:01.000
out to the rest of the network.

126
07:01.000 --> 07:05.640
So the service route gives me that opportunity.

127
07:05.640 --> 07:10.450
So what we find at the end of the day here is that OMP is responsible for

128
07:10.450 --> 07:11.840
sharing routes.

129
07:11.840 --> 07:18.650
That's great, but it also allows me to push policy and it allows me to form

130
07:18.650 --> 07:19.880
tunnels.

131
07:19.880 --> 07:23.860
It brings everything together from a control plane perspective and we can see

132
07:23.860 --> 07:24.680
why something

133
07:24.680 --> 07:28.400
like EIDGRP or OSPF wouldn't do the job.

134
07:28.400 --> 07:33.080
And even BGP, we could adapt BGP for this purpose, but we see that we want
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

134
07:28.400 --> 07:33.080
And even BGP, we could adapt BGP for this purpose, but we see that we want

135
07:33.080 --> 07:33.880
these three

136
07:33.880 --> 07:39.520
different route types and so there's a reason why Viptela and by extension

137
07:39.520 --> 07:42.080
Cisco ended up creating

138
07:42.080 --> 07:46.290
this custom protocol in order to carry all of the information needed to glue

139
07:46.290 --> 07:46.840
our SD-WAN

140
07:46.840 --> 07:47.840
environment together.