|
0:00:14
|
Welcome back everybody to CCIE InterNetwork Expert
|
|
0:00:16
|
CCIE Routing and Switching Advanced Technologies Class.
|
|
0:00:20
|
In today's class sessions, we're gonna continue our discussion of BGP,
|
|
0:00:24
|
and we're gonna look at some more of the advanced topics
|
|
0:00:26
|
of how to customize the BGP policy
|
|
0:00:29
|
for doing different types of advertisements,
|
|
0:00:32
|
and changing the routing policy in terms of the best path selection aggregation,
|
|
0:00:37
|
and a bunch of other advanced features
|
|
0:00:39
|
that are minor modifications of how the BGP process works.
|
|
0:00:44
|
Now, the topology that we're gonna be using today
|
|
0:00:46
|
is the same physical one that we have been using up to this point,
|
|
0:00:50
|
but from the diagram, we can see that the network is now split into
|
|
0:00:53
|
a couple different autonomous systems where we have AS numbers 100 through 400
|
|
0:00:58
|
that I'm gonna be making configuration changes to.
|
|
0:01:01
|
Then, we have a couple different external autonomous systems.
|
|
0:01:04
|
AS 54 on BB1 and BB3,
|
|
0:01:07
|
and AS 254 on BB2
|
|
0:01:10
|
that is gonna be injecting prefixes into the network.
|
|
0:01:13
|
So, up to this point, we talked about the general peering logic of BGP.
|
|
0:01:18
|
How we establish the control plane for the TCP sessions,
|
|
0:01:22
|
how we change where the session is coming from
|
|
0:01:25
|
with features like the update source,
|
|
0:01:27
|
different peering optimizations, like the EBGP multi-hop, the TTL security.
|
|
0:01:34
|
So, essentially, everything up to this point
|
|
0:01:36
|
was just establishing the basic BGP control plane.
|
|
0:01:40
|
Once the BGP network is up and running,
|
|
0:01:42
|
Then, our next step would be to do...
|
|
0:01:44
|
network layer reachability advertisements into BGP,
|
|
0:01:48
|
which is gonna be our prefix origination for
|
|
0:01:51
|
the network statement or redistribution.
|
|
0:01:54
|
And once prefixes are actually learned by the different BGP peers,
|
|
0:01:58
|
then, we can customize ultimately what our routing policy is gonna be.
|
|
0:02:03
|
So, the next thing we're gonna look at here is
|
|
0:02:05
|
that different type of ways that we can originate prefixes into BGP.
|
|
0:02:10
|
We know, the most basic one is gonna be the network statement,
|
|
0:02:15
|
which is used to originate any type of route that is locally in the routing table.
|
|
0:02:21
|
Now, this prefix doesn't necessarily have to be a connected route.
|
|
0:02:24
|
It could be anything that's learned from IGP,
|
|
0:02:27
|
it could be anything that's installed from static routing.
|
|
0:02:30
|
As long as the router has a copy of the prefix in the routing table,
|
|
0:02:33
|
the BGP router can originate it into the BGP table.
|
|
0:02:38
|
Now, we'll actually see in a lot of designs,
|
|
0:02:40
|
it's very common for the edge routers
|
|
0:02:43
|
to originate prefixes on the half of the internal network.
|
|
0:02:46
|
So, as long as the edge routers have IGP reachability
|
|
0:02:50
|
to the internal routers, then, they can originate the networks on behalf of them.
|
|
0:02:56
|
We talked a little bit about with redistribution with BGP before.
|
|
0:03:00
|
Really, the only key point to watch out for this
|
|
0:03:02
|
is that when we are redistributing OSPF into BGP.
|
|
0:03:06
|
It's not automatically going to include our OSPF external routes.
|
|
0:03:11
|
So, we would need to say, Redistribute OSPF 1 Match Internal External
|
|
0:03:16
|
in order to make sure the E1, E2, N1, or N2 route are actually advertised into the BGP domain.
|
|
0:03:24
|
Then, a pretty large topic we're gonna look at today,
|
|
0:03:27
|
which is aggregation. To take prefixes that are already in the BGP table,
|
|
0:03:31
|
and then summarize them to shorter match aggregates.
|
|
0:03:35
|
And we'll see with the policies that are available in BGP,
|
|
0:03:38
|
there's a lot of granular control
|
|
0:03:41
|
that we have over how we are originating the aggregate.
|
|
0:03:44
|
What are the different attributes of the aggregate,
|
|
0:03:47
|
and then, how even the subnets or the summary itself are advertised to the different BGP peers.
|
|
0:03:54
|
Then lastly, we'll look at a less common feature, which is known as the BGP Conditional Route Injection,
|
|
0:03:59
|
or the BGP Inject Map,
|
|
0:04:01
|
which is essentially the opposite of aggregation.
|
|
0:04:05
|
We'll see with the BGP Inject Map, we're taking a shorter match
|
|
0:04:09
|
like a /20 aggregate.
|
|
0:04:12
|
Then, based on that, we could generate subnets
|
|
0:04:14
|
from the aggregate in order for the purpose of traffic engineering.
|
|
0:04:18
|
So, we could take a /20 summary, and generate two /21s.
|
|
0:04:23
|
Or four /22s.
|
|
0:04:24
|
So, the different BGP peers
|
|
0:04:27
|
can do their path selection based on a longer match
|
|
0:04:30
|
as opposed to the less specific summary match.
|
|
0:04:34
|
So again, our first option here,
|
|
0:04:36
|
before originating the prefixes is gonna be with the network statement.
|
|
0:04:40
|
Now, unlike the network statement in either OSPF or EIGRP,
|
|
0:04:44
|
in BGP, this does actually mean what prefixes that we are originating into the topology.
|
|
0:04:50
|
Where in the case of OSPF or EIGRP,
|
|
0:04:53
|
it simply means, what are the interfaces that we are running the protocol on.
|
|
0:04:57
|
But as we saw it previously with BGP,
|
|
0:05:00
|
the peerings are not associated on a per-interface basis.
|
|
0:05:04
|
They're associated just based on the logical TCP control plane session between the neighbors.
|
|
0:05:10
|
Now, one of the differences we'll see with this when we actually look at the routing table
|
|
0:05:14
|
of a BGP learned route as opposed to an IGP learned route,
|
|
0:05:18
|
the route recursion to the outgoing interface is not automatically performed for BGP.
|
|
0:05:24
|
And the reason why is that when we're learning the routes from a peer,
|
|
0:05:27
|
they're not coming in any particular interface.
|
|
0:05:31
|
They're coming from the logical TCP session.
|
|
0:05:33
|
Then, it's up to us to use IGP
|
|
0:05:36
|
to perform the ultimate route recursion
|
|
0:05:39
|
in order to figure out where the actual outgoing interface is.
|
|
0:05:42
|
Now, some of the attributes of the BGP network statement,
|
|
0:05:45
|
first and foremost is that it's gonna be originating prefixes with the origin code of IGP.
|
|
0:05:51
|
And we'll see this in the rightmost portion of the output of the Show IP BGP command,
|
|
0:05:57
|
where the other origin codes would be EGP
|
|
0:06:01
|
for the actual protocol, Exterior Gateway Protocol,
|
|
0:06:04
|
which was the pre-cursor to BGP.
|
|
0:06:07
|
Then, the origin code of imcomplete,
|
|
0:06:09
|
which we see in the status code is a question mark,
|
|
0:06:12
|
which will be used for any redistribution,
|
|
0:06:15
|
or also the BGP conditional route injection.
|
|
0:06:20
|
So, we'll see when we get to the BGP best path selection,
|
|
0:06:23
|
the origin code is used as part of the path selection in BGP,
|
|
0:06:27
|
which means that a prefix generated by the network statement
|
|
0:06:30
|
would be more preferred than one that is generated with either redistribution,
|
|
0:06:34
|
or with the conditional route injection feature.
|
|
0:06:38
|
Additionally, as I mentioned,
|
|
0:06:39
|
the only requirement of network statement in BGP
|
|
0:06:43
|
is that there'll be a match in the routing table.
|
|
0:06:46
|
So, as long as we have either the connected prefix,
|
|
0:06:49
|
or the route learned for IGP,
|
|
0:06:52
|
or a static route configured,
|
|
0:06:53
|
then, we can originate that particular prefix into the BGP table.
|
|
0:06:58
|
Now, syntax wise,
|
|
0:07:00
|
we need to make sure that whatever network that we are originating
|
|
0:07:03
|
is an exact match of both the prefix and the prefix length.
|
|
0:07:08
|
That means that if I have the prefix 10.0.0.0/24
|
|
0:07:13
|
that I'm trying to advertise into BGP,
|
|
0:07:15
|
I would need to add the mask argument to tell the router
|
|
0:07:19
|
that the address 10.0.0.0 has a prefix length of 255.255.255.0.
|
|
0:07:26
|
So, without the mask keyword, the process is gonna assume that the network is classful.
|
|
0:07:31
|
And unless we actually have the prefix 10.0.0.0/8,
|
|
0:07:36
|
it's not going to be automatically originated in the BGP table.
|
|
0:07:42
|
So, we'll see, once we're done with the origination, we're gonna look at the Show IP BGP,
|
|
0:07:45
|
or the Show IP BGP Regular Expression caret dollar sign (^$)
|
|
0:07:49
|
to look at routes that are locally originated inside our autonomous system
|
|
0:07:54
|
to make sure whatever prefix we're matching is actually advertised into the process.
|
|
0:07:59
|
So, let's take a look at our topology here,
|
|
0:08:01
|
and we'll start in BGP AS 100 that is between router 1, 4, and 6.
|
|
0:08:07
|
And the way that I have the peerings set up is essentially a full mesh
|
|
0:08:12
|
of the external peers for anyone that is directly connected.
|
|
0:08:17
|
So, for example, on router 6, we have a peering that goes to switch 1,
|
|
0:08:20
|
and to BB1,
|
|
0:08:22
|
on router 1, we have peerings with router 3, and router 5.
|
|
0:08:27
|
Then, between router 4 and 5,
|
|
0:08:31
|
5 and 3, 5 and 2, 3 and 2, etc.
|
|
0:08:35
|
Now, internal to the autonomous systems,
|
|
0:08:38
|
it technically doesn't matter what the peering design is.
|
|
0:08:42
|
As long as anyone can learn any of the prefixes that are learned by the border routers.
|
|
0:08:47
|
So, some of these autonomous systems, like AS 300 and 400,
|
|
0:08:51
|
I have route reflection configured,
|
|
0:08:54
|
where specifically switch 2 and switch 2
|
|
0:08:57
|
are route reflectors for their clients, router 5 and switch 4 in AS 400.
|
|
0:09:03
|
And switch 1 has clients router 3 and switch 3 in AS 300.
|
|
0:09:07
|
Whereas inside AS 100, I simply have a full mesh of the iBGP peers.
|
|
0:09:15
|
So, we'll see, from a best path selection point of view,
|
|
0:09:18
|
it's really not gonna matter what the internal peering structure in these autonomous systems are,
|
|
0:09:22
|
because the traffic flow would follow the only possible physical path.
|
|
0:09:26
|
For example, from switch 4, in order to reach AS 100,
|
|
0:09:31
|
there's no other possible path but to go to switch 2, and then to go to router 5.
|
|
0:09:37
|
So, whether we were to have a full mesh there, or use route reflection, or confederation,
|
|
0:09:42
|
the ultimate route recursion is always gonna point towards
|
|
0:09:45
|
that port channel interface that's between switch 2 and switch 4.
|
|
0:09:50
|
So, as long as all the neighbors are actually able to learn the prefixes,
|
|
0:09:54
|
that's really what we ultimately care about.
|
|
0:09:59
|
So, let's take a look at the command line on router 1,
|
|
0:10:02
|
and we're going to originate some prefixes into BGP,
|
|
0:10:05
|
and then see what the rest of the devices in the topology can see this as.
|
|
0:10:11
|
So, from router 1, first, let's look at the Show IP BGP Summary.
|
|
0:10:15
|
And we wanna make sure that there's nothing wrong with the peerings between the neighbors.
|
|
0:10:19
|
Because again, when we're working in the configuration for BGP or the troubleshooting,
|
|
0:10:23
|
we always wanna do a basic verification from the lower layers up.
|
|
0:10:28
|
So, if I Show IP BGP Summary,
|
|
0:10:30
|
and I see that some of the peers are not working,
|
|
0:10:32
|
probably, the first thing that I would wanna check
|
|
0:10:35
|
is do I actually have transport to that address?
|
|
0:10:38
|
So, we can see, inside AS 100,
|
|
0:10:41
|
I have the peers that are router 4's loopback and router 6's loopback.
|
|
0:10:44
|
From router 1's perspective, if I was not able to reach either of these addresses,
|
|
0:10:51
|
then, we would not be able to establish the peering.
|
|
0:10:54
|
Because again, BGP is using TCP for its transport,
|
|
0:10:57
|
which assumes that we have some sort of underlying IGP
|
|
0:11:01
|
in order to allow us to establish the session.
|
|
0:11:05
|
Once the session is up,
|
|
0:11:07
|
we verify this with the Show IP BGP Summary.
|
|
0:11:10
|
Next thing to look at would be the Show IP BGP,
|
|
0:11:12
|
which is the actual BGP table
|
|
0:11:15
|
that contains the updates that we're receiving from the neighbors.
|
|
0:11:20
|
So, we could see, at this point,
|
|
0:11:22
|
we have prefixes that are originated in AS 54 and AS 254.
|
|
0:11:28
|
We can see this based on the AS path information
|
|
0:11:30
|
on the right most portion of the output.
|
|
0:11:33
|
And for AS 254,
|
|
0:11:35
|
there's a couple different diverse AS paths that we could go through.
|
|
0:11:40
|
We could go through either AS 300 to 200, or AS 400 to 200.
|
|
0:11:46
|
So, once we actually get into the BGP best path selection,
|
|
0:11:49
|
then, we'll look at all of the attributes that are making up the path selection for BGP,
|
|
0:11:53
|
and talk about how we can prefer one path over the other
|
|
0:11:57
|
by influencing our routing policy.
|
|
0:12:00
|
So, up to this point, we're learning prefixes from the remote autonomous systems,
|
|
0:12:05
|
but since we're not actually advertising anything into BGP,
|
|
0:12:08
|
it means that none of these internal routers
|
|
0:12:10
|
are actually gonna have reachability to any of these prefixes.
|
|
0:12:15
|
So, within the scope of the exam,
|
|
0:12:17
|
it really doesn't make sense to run BGP
|
|
0:12:20
|
and then end up in a case where we don't actually have reachability to the prefixes that we're learning.
|
|
0:12:26
|
So, whether this is actually gonna be a requirement of the exam,
|
|
0:12:29
|
we should be able to see this based on
|
|
0:12:31
|
the particular question where it says,
|
|
0:12:33
|
either you need reachability to all of the destinations,
|
|
0:12:37
|
or maybe from a grading point of view,
|
|
0:12:39
|
the proctors are just looking at the Show IP BGP Output
|
|
0:12:42
|
to see if you're implementing a certain type of policy.
|
|
0:12:45
|
So, don't assume that there's any
|
|
0:12:48
|
general requirements
|
|
0:12:49
|
that are gonna course on to all of the exams.
|
|
0:12:52
|
You simply have to look at the specific requirements that are listed
|
|
0:12:56
|
in the beginning section of that exam,
|
|
0:12:58
|
and then, anything that's specified on an individual task basis.
|
|
0:13:04
|
But again, in our particular case here, since we're not actually advertising anything into BGP,
|
|
0:13:09
|
we're not gonna be able to reach any of these prefixes that we're learning.
|
|
0:13:13
|
So, to fix this, the first thing I'm gonna do inside AS 100
|
|
0:13:17
|
is advertise the loopback addresses of the different routers.
|
|
0:13:22
|
Now, inside these different autonomous systems, I already have IGP running.
|
|
0:13:27
|
Inside AS 100, I'm running OSPF.
|
|
0:13:30
|
Inside AS 300, we're running EIGRP.
|
|
0:13:34
|
And then, likewise in AS 400, we're running EIGRP.
|
|
0:13:38
|
Because as we know, without the underlying IGP reachability,
|
|
0:13:41
|
we're not gonna be able to establish the TCP sessions,
|
|
0:13:44
|
and then, we potentially would have issues with next hop reachability
|
|
0:13:48
|
for the BGP prefixes that we are learning.
|
|
0:13:54
|
So, in AS 100,
|
|
0:13:56
|
on router 1, let's look at the Show IP Route OSPF
|
|
0:13:59
|
to look at our IGP networks.
|
|
0:14:01
|
And we see that we are learning the...
|
|
0:14:05
|
exit points out of the network.
|
|
0:14:08
|
So, for example, the link that connects
|
|
0:14:10
|
router 4 to BB3.
|
|
0:14:12
|
The link that connects BB1 to router 6.
|
|
0:14:16
|
This means that when we learn prefixes from any of our EBGP neighbors,
|
|
0:14:21
|
which would be BB1 and BB3,
|
|
0:14:25
|
then, these prefixes are advertised into the iBGP network.
|
|
0:14:30
|
Since by default, the next hop value is not gonna be changed,
|
|
0:14:33
|
it means that router 1 would need reachability to BB1's address...
|
|
0:14:37
|
and the link to BB3
|
|
0:14:39
|
in order to do route recursion for those particular destinations.
|
|
0:14:45
|
So, before implementing any type of routing policy,
|
|
0:14:47
|
changing the best path selection,
|
|
0:14:49
|
doing any type of filtering, aggregation,
|
|
0:14:51
|
we need to make sure that these underlying design issues are solved for BGP.
|
|
0:14:56
|
Because otherwise, we can end up in a configuration
|
|
0:14:59
|
that has the correct commands,
|
|
0:15:01
|
but then is not actually functional.
|
|
0:15:03
|
And in general, you will see in the exam
|
|
0:15:05
|
that the exam is rated based on functionality, not based on just the configuration.
|
|
0:15:13
|
So, if your network doesn't actually work at the end of the day,
|
|
0:15:16
|
then, it's unlikely that you're gonna get credit for those particular sections.
|
|
0:15:19
|
Now, additionally, we could see on router 1 that the two loopback
|
|
0:15:23
|
we're learning from OSPF, these have subnet masks of /32.
|
|
0:15:27
|
This is because be default, these are running as network type point-to-point.
|
|
0:15:33
|
Now, this were to mean on router 1, if I were to go under the BGP process,
|
|
0:15:38
|
and specify a network statement
|
|
0:15:40
|
that matches router 6's loopback,
|
|
0:15:44
|
that matches router 4's loopback, and then matches router 1's loopback locally.
|
|
0:15:50
|
Since the first two prefixes do not have an exact match in the routing table,
|
|
0:15:55
|
it means that router 1 is not gonna be able to generate these.
|
|
0:16:00
|
So, if we were to look at the Show IP BGP,
|
|
0:16:02
|
Regular Expression caret dollar sign (^$),
|
|
0:16:06
|
which again is gonna be for our locally originated prefixes inside our own autonomous system.
|
|
0:16:12
|
And actually, this should say 150, not 155.
|
|
0:16:15
|
So, let's say, Show Run Section Router...
|
|
0:16:21
|
Router BGP.
|
|
0:16:28
|
And I need to change these from 155 to...
|
|
0:16:35
|
150.
|
|
0:16:39
|
So, like I mentioned before, since a lot of these configurations are gonna be
|
|
0:16:42
|
fairly repetitive for BGP,
|
|
0:16:45
|
a lot of the times, it's just easier to just do this in Notepad
|
|
0:16:48
|
to make sure that there's no discrepancies between the different devices.
|
|
0:16:53
|
So, on router 1, let's go back on to Router BGP 100.
|
|
0:16:56
|
I'm gonna remove the old network statement and then,
|
|
0:17:00
|
put in the correct one. So, 150.28.1.0.
|
|
0:17:06
|
Now, also, just based on my basic verification here
|
|
0:17:09
|
looking at the Show IP BGP Output,
|
|
0:17:11
|
that would have told me that there was something wrong in either the network statement that I was putting in,
|
|
0:17:16
|
or those prefixes didn't actually exist.
|
|
0:17:20
|
So, within the scope of the lab exam,
|
|
0:17:22
|
it's really easy to make mistakes like that where you're putting the wrong address,
|
|
0:17:25
|
or maybe you're transposing two different digits,
|
|
0:17:28
|
and it can be very frustrating to try to troubleshoot something like that
|
|
0:17:32
|
especially later in the day when you've already been looking at the configuration for 6 or 7 hours.
|
|
0:17:38
|
So, a lot of the times, it's much harder to debug
|
|
0:17:41
|
the actual running config
|
|
0:17:44
|
as opposed to looking at the verifications and looking for the correct output that you would expect.
|
|
0:17:49
|
So, previously, based on the fact that I didn't see anything when I said Show IP BGP,
|
|
0:17:53
|
regexp caret dollar sign (^$), then, it's telling me that there was something wrong with the...
|
|
0:17:58
|
network statements.
|
|
0:18:05
|
So now, we can see on router 1 that it's originating the
|
|
0:18:08
|
network for its own local loopback,
|
|
0:18:10
|
but not for the loopbacks for router 4 and router 6.
|
|
0:18:15
|
And again, the reason why,
|
|
0:18:16
|
when we look at the IGP routing table,
|
|
0:18:21
|
I specified the /24 under the BGP process
|
|
0:18:24
|
where in the IGP table, I actually have the /32s.
|
|
0:18:28
|
So, either I could change the BGP network statement to match what IGP has,
|
|
0:18:33
|
or on router 4 and router 6,
|
|
0:18:36
|
which I'm gonna do here is to go to the loopback interface
|
|
0:18:39
|
and say, IP OSPF Network Point-to-Point.
|
|
0:18:46
|
So, we'll see in some other applications later
|
|
0:18:48
|
that we get to,
|
|
0:18:50
|
this discrepancy between the...
|
|
0:18:54
|
the actual mask of the interface versus what's being advertised for OSPF,
|
|
0:18:59
|
this can have a negative impact on certain other designs.
|
|
0:19:02
|
We'll look at cases in Layer 3 MPLS VPNs that this is gonna be a problem,
|
|
0:19:07
|
and then, some of the other miscellaneous features later.
|
|
0:19:11
|
So, on router 1,
|
|
0:19:13
|
4, and 6, I wanna change this on the...
|
|
0:19:16
|
the loopback.
|
|
0:19:25
|
Once this is done, we should now be able to look at the Show IP BGP.
|
|
0:19:30
|
Reg expression caret dollar sign (*$) again.
|
|
0:19:34
|
Because when we're looking at the autonomous system path here,
|
|
0:19:38
|
the path value is empty because I'm the one who's locally originating the prefix.
|
|
0:19:44
|
So, the AS number 100, which is my local AS,
|
|
0:19:47
|
that's actually not advertised on
|
|
0:19:49
|
until the prefix goes to the EBGP peers.
|
|
0:19:53
|
So, it's prepended at the edge of the network, not where I'm locally originating it.
|
|
0:20:00
|
Now, if we look at these specific prefixes,
|
|
0:20:02
|
we can tell some of the differences between the one that was local on router 1.
|
|
0:20:08
|
Where 150.28.1.0/24 is the connected loopback on router 1.
|
|
0:20:15
|
We can see that in this case, the next hop is 0.0.0.0, which means it's a local prefix.
|
|
0:20:21
|
And the metric is zero, which is the BGP med,
|
|
0:20:24
|
because all connected interfaces will have a metric of zero.
|
|
0:20:29
|
We see that for router 4 and router 6's loopbacks,
|
|
0:20:32
|
these have a non-zero med value,
|
|
0:20:36
|
and this is the cost that we are inheriting from the IGP process.
|
|
0:20:41
|
So, by default, when we issue the network statement under BGP,
|
|
0:20:45
|
if the network statement is matching an IGP learned route,
|
|
0:20:49
|
we're gonna copy the IGP metric to the BGP med.
|
|
0:20:54
|
We'll see also, this is the case when we do redistribution.
|
|
0:20:57
|
If I were to redistribute OSPF into BGP.
|
|
0:20:59
|
Then, the OSPF cost value is automatically gonna be copied to the BGP med value.
|
|
0:21:09
|
We'll see that when we get into the specifics of the best path selection,
|
|
0:21:12
|
the med value is not an non-transitive attribute.
|
|
0:21:16
|
So, this means that these values are not gonna be sent to the external neighbors.
|
|
0:21:22
|
So, it's only when I'm setting the med value manually on the outbound sessions
|
|
0:21:28
|
is it going to affect the remote autonomous systems.
|
|
0:21:31
|
So, for example, if we were to go to
|
|
0:21:34
|
someone that is outside of AS 100.
|
|
0:21:37
|
Let's say we go to router 2.
|
|
0:21:40
|
And from router 2, we'll look at the...
|
|
0:21:44
|
Show IP BGP.
|
|
0:21:48
|
We see that for those three loopback addresses, the 150.28, 1, 4, and 6,
|
|
0:21:54
|
the med value has been reset to null.
|
|
0:21:59
|
So from router 2's perspective, since it's multiple AS hops away,
|
|
0:22:03
|
that med value is not gonna be significant to AS 200.
|
|
0:22:16
|
So, pretty straightforward implementation here.
|
|
0:22:19
|
Again, the main key point is that
|
|
0:22:21
|
we need the exact match in the routing table in order to generate the network.
|
|
0:22:27
|
Once we do that, the origin is going to be IGP,
|
|
0:22:30
|
the med value is gonna be copied automatically from the IGP cost.
|
|
0:22:36
|
And then, at this point, we should be able to get reachability
|
|
0:22:40
|
to any of the BGP prefixes when we're now sourcing traffic from these loopbacks.
|
|
0:22:45
|
So, from router 1, if we Show IP Route BGP,
|
|
0:22:49
|
let's pick the first prefix for example, I should now be able to ping 119.0.0.1,
|
|
0:22:54
|
but as long as I'm sourcing traffic from my loopback zero.
|
|
0:22:59
|
So, when we're doing connectivity testing with BGP,
|
|
0:23:03
|
it's important to keep in mind what are the actual prefixes that are originated into the BGP network,
|
|
0:23:09
|
because in a real design, generally, the transit links are not gonna be advertised into BGP.
|
|
0:23:17
|
So, let's say for example that we are AS 400.
|
|
0:23:21
|
And we're trying to route our traffic out on to the Internet.
|
|
0:23:24
|
Assuming that this Ethernet between router 5 and switch 2 is a point-to-point Ethernet segment,
|
|
0:23:31
|
a lot of the times, that prefix is actually not gonna be advertised into BGP.
|
|
0:23:36
|
It's only gonna be the segments where the actual end services are located
|
|
0:23:40
|
whether there are web servers or end clients,
|
|
0:23:43
|
which in this case would be the VLAN 10 and the VLAN 8.
|
|
0:23:49
|
Now, the implication of this
|
|
0:23:51
|
is that if I'm gonna test the reachability of the BGP network from either switch 2 or switch 4,
|
|
0:23:56
|
it would make sense that I would have to change the source of where I'm generating my pings from
|
|
0:24:01
|
to be either of the VLAN 8 on switch 2, or the VLAN 10 interface on switch 4.
|
|
0:24:10
|
So, within the scope of the lab exam, we do need to be aware of...
|
|
0:24:14
|
what the proctor is gonna be testing for when they're actually gonna be grading the section.
|
|
0:24:19
|
So, whether they're looking for the actual reachability,
|
|
0:24:21
|
or whether they're just looking for the BGP table to look a certain way.
|
|
0:24:24
|
You need to know that because that's ultimately going to affect
|
|
0:24:27
|
what particular solution you're choosing for the design.
|
|
0:24:45
|
Our next case here for originating prefixes in the BGP
|
|
0:24:49
|
is gonna be with redistribution.
|
|
0:24:52
|
Where we could either redistribute our connected prefixes.
|
|
0:24:55
|
We could redistribute static routes, we could redistribute IGP routes in the BGP.
|
|
0:24:59
|
Again, really, the only restriction of this
|
|
0:25:02
|
is that the external OSPF routes are not gonna be included by default.
|
|
0:25:08
|
So, if we redistribute EIGRP in the BGP,
|
|
0:25:11
|
both the internal and the external EIGRP routes will automatically be originated.
|
|
0:25:17
|
We redistribute OSPF and we do want the externals.
|
|
0:25:20
|
We would need to say match internal-external.
|
|
0:25:24
|
We'll see this is especially gonna be important when we get to Layer 3 MPLS VPNs.
|
|
0:25:30
|
And we're using OSPF as the provider edge to customer edge routing protocol,
|
|
0:25:35
|
where the PE to CE routing protocol.
|
|
0:25:38
|
If the service provider is learning external OSPF routes from the customer,
|
|
0:25:44
|
in order to originate those into the MPLS network,
|
|
0:25:47
|
we would need to say match internal-external under the BGP process.
|
|
0:25:55
|
Now, in any case, just like we looked at before,
|
|
0:25:57
|
the easy way to verify this just to look at the Show IP BGP.
|
|
0:26:02
|
So, if we look at the BGP table and we see that the prefixes have not been originated,
|
|
0:26:06
|
then we know that's a potential problem with our configuration.
|
|
0:26:15
|
Again, as I mentioned, when we're using the network statement under BGP,
|
|
0:26:18
|
the origin code is gonna be set to IGP.
|
|
0:26:22
|
Whereas with redistribution, origin code is gonna be set to incomplete,
|
|
0:26:26
|
which we see as the status code or the origin code question mark
|
|
0:26:32
|
to the right most portion of the BGP output. The Show IP BGP Output.
|
|
0:26:38
|
So, here from router 1, if we were to look at the Show IP BGP,
|
|
0:26:42
|
we see next to the autonomous system path, the prefixes that were originated by AS 254,
|
|
0:26:48
|
these have the origin code incomplete.
|
|
0:26:52
|
So, it either means that these was redistributed
|
|
0:26:55
|
that they were using BGP conditional route injection.
|
|
0:26:59
|
Or they were manually set to the origin code incomplete when they were being originated.
|
|
0:27:06
|
And again, this is part of the BGP best path selection process.
|
|
0:27:10
|
So, if I already have a prefix originated by the network statement versus redistribution.
|
|
0:27:14
|
If everything is equal up to that point, like the weight, the local preference.
|
|
0:27:19
|
Then I would prefer the prefix originated by the network statement as opposed to the redistribution.
|
|
0:27:33
|
So, let's look at this from AS 400's perspective.
|
|
0:27:37
|
Which is router 5, switch 2 and switch 4.
|
|
0:27:41
|
And we are gonna originate our IGP learned prefixes.
|
|
0:27:46
|
Which are gonna include our loopbacks and then these transit interfaces.
|
|
0:27:50
|
And we're gonna redistribute these into the BGP process.
|
|
0:27:55
|
So, let's go to router 5 and let's look at the Show IP Route EIGRP.
|
|
0:28:01
|
If I were to redistribute EIGRP into BGP,
|
|
0:28:05
|
just like we talked about with any of the other routing protocols,
|
|
0:28:08
|
the redistribution is happening fromthe routing table, not from the routing database.
|
|
0:28:16
|
So, for some reason, there are prefixes in the EIGRP topology
|
|
0:28:20
|
that are not getting installed in the routing table.
|
|
0:28:23
|
It would mean that these are not candidate to be redistributed into BGP.
|
|
0:28:28
|
And as we saw previously in the redistribution section,
|
|
0:28:31
|
typically, the reason that that would happen
|
|
0:28:33
|
is that if I have a route learned from EIGRP
|
|
0:28:36
|
but then I have some other prefix that is the same longest match,
|
|
0:28:40
|
but it has a lower administrative distance.
|
|
0:28:46
|
The end result of that we saw when we looked at the Show IP EIGRP Topology
|
|
0:28:50
|
is that the feasible distance is listed as inaccessible.
|
|
0:28:55
|
Which means the prefix cannot be installed in the routing table,
|
|
0:28:58
|
which then implies it cannot be advertised to any other peers.
|
|
0:29:02
|
Which in this case, the peer would be advertised to is the actual BGP process.
|
|
0:29:09
|
So, now on router 5, if I were to redistribute EIGRP into BGP,
|
|
0:29:13
|
we should see that it's gonna include these five prefixes that were learned dynamically.
|
|
0:29:19
|
Plus if we look at the Show IP Protocols,
|
|
0:29:27
|
we should see that it's going to include any connected links that are running the EIGRP process.
|
|
0:29:32
|
So, in this case, I have my WAN interfaces, which are serial 0.0.0,
|
|
0:29:38
|
serial 0.1.0, those are running as passive links.
|
|
0:29:43
|
Then I'm also advertising my LAN interface. The connection to switch 2.
|
|
0:29:50
|
We can also see this from the Show IP EIGRP Interfaces.
|
|
0:29:57
|
So, if I were to simply go to the BGP process,
|
|
0:30:00
|
which in this case is AS 400.
|
|
0:30:02
|
And then say Redistribute EIGRP.
|
|
0:30:05
|
And in this case, it's EIGRP AS 400.
|
|
0:30:08
|
I don't need to set a metric value here.
|
|
0:30:11
|
Because the BGP process is going to infer this already from the IGP metric.
|
|
0:30:18
|
Now, technically, we don't even need a metric value.
|
|
0:30:21
|
Because the BGP med is for the vast majority cases is not gonna be used for the path selection.
|
|
0:30:27
|
It's much more common for the local preference or the AS path
|
|
0:30:31
|
to be used as the path selection decision.
|
|
0:30:36
|
Unless we're trying to do some sort of multipath internal to the iBGP network.
|
|
0:30:44
|
Now, if we look at the result of this on router 5,
|
|
0:30:46
|
let's say Show IP BGP Regular Expression caret dollar sign (^$),
|
|
0:30:52
|
and we see now there's a bunch of prefixes that have been originated.
|
|
0:30:56
|
Some of these have a next hop value of 0.0.0.0,
|
|
0:31:00
|
which means these are my connected routes.
|
|
0:31:03
|
The other ones include the loopbacks of switch 2 and switch 4.
|
|
0:31:07
|
The LAN Interfaces of switch 2 and switch 4 and then the transit link between switch 2 and switch 4.
|
|
0:31:14
|
So, it's essentially everything that's in the routing table as EIGRP.
|
|
0:31:17
|
Plus my connected interfaces that are running the process.
|
|
0:31:23
|
Now, typically, in a real design, if we were to do this type of configuration and redistribute prefixes into BGP,
|
|
0:31:30
|
normally, you're not gonna include just everything.
|
|
0:31:33
|
You would wanna put some sort of administrative filter on here
|
|
0:31:36
|
to make sure that you're not accidentally leaking prefixes that should not be advertised out to the global BGP table.
|
|
0:31:44
|
So, if I had some internal address space that's RFC 1918.
|
|
0:31:47
|
Or maybe some link local space or something else that's not routable,
|
|
0:31:51
|
I wanna make sure that these prefix ranges are not advertising to global BGP.
|
|
0:32:00
|
So, the easiest way to do this, just like filtering for IGP redistribution,
|
|
0:32:04
|
or be to add a route-map on to the redistribute statement.
|
|
0:32:09
|
So, let's say here on router 5,
|
|
0:32:12
|
"I want to include my connected loopback."
|
|
0:32:15
|
The loopback of switch 2 and the loopback of switch 4.
|
|
0:32:19
|
But I don't wanna advertise any of the prefixes into the BGP process.
|
|
0:32:25
|
So, I could match these prefixes with an access list both a standard or an extended list.
|
|
0:32:31
|
Or I could match it with a prefix list.
|
|
0:32:35
|
We'll see a little bit later when we get into details of filtering with BGP.
|
|
0:32:39
|
There's a lot of different ways that you can accomplish the same thing.
|
|
0:32:42
|
But in general,
|
|
0:32:44
|
whenever you are matching routes,
|
|
0:32:46
|
the easiest solution is touse a prefix list.
|
|
0:32:50
|
So, on router 5, I'll say IP Prefix List EIGRP to BGP Prefixes
|
|
0:32:58
|
I'm gonna permit 150.28.5.0/24.
|
|
0:33:04
|
8.0 and 10.0.
|
|
0:33:12
|
Once I've matched the routes in question, then I'm gonna call these from a route-map
|
|
0:33:16
|
and then use that to filter the redistribution.
|
|
0:33:19
|
So, I'll say Route-Map EIGRP to BGP.
|
|
0:33:25
|
The default sequence number is gonna 10.
|
|
0:33:28
|
The default action is Permit for the route-map if I don't specify.
|
|
0:33:32
|
Then I'm going to match IP Address Prefix List EIGRP to BGP Prefixes.
|
|
0:33:43
|
Now, again, when I do this just like under the IGP process,
|
|
0:33:47
|
I want to make sure that I'm not saying Match IP Address EIGRP to BGP Prefixes
|
|
0:33:53
|
because this would be calling a named to access list
|
|
0:33:57
|
as opposed to a prefix list.
|
|
0:34:01
|
So, it's a common syntax error here that the router's not gonna give you an errror message saying,
|
|
0:34:05
|
"The Access List EIGRP to BGP Prefix List doesn't exist."
|
|
0:34:09
|
It looks like that configuration's valid.
|
|
0:34:11
|
But then when we actually look at the BGP table,
|
|
0:34:13
|
we would see that the prefixes are not actually gonna get advertised.
|
|
0:34:17
|
So, we need to make sure to add that keyword prefix list.
|
|
0:34:25
|
Then lastly, under the BGP Process,
|
|
0:34:28
|
we'll change the redistribution statement
|
|
0:34:32
|
that says, "Redistribute EIGRP 400." But now, we're gonna use the route-map
|
|
0:34:37
|
EIGRP to BGP.
|
|
0:34:43
|
So, once this is filtered, if we look at the Show IP BGP Regular Expression caret dollar sign (^$),
|
|
0:34:50
|
We should see that those other prefixes are withdrawn.
|
|
0:34:55
|
If we were to look at the Debug IP BGP Updates anywhere in the network,
|
|
0:34:58
|
we would have seen that router 5 is generating a withdraw message.
|
|
0:35:03
|
Which is essentially an update that says "I need to remove this particular prefix from the BGP topology."
|
|
0:35:15
|
So, then just like we tested on router 1, we should be able to go to any of these three peers.
|
|
0:35:20
|
For example, on switch 4,
|
|
0:35:23
|
look at now the Show IP Route BGP,
|
|
0:35:27
|
we should now be able to reach any of these routes.
|
|
0:35:29
|
Let's say 222.22.2.1
|
|
0:35:33
|
as resourcing traffic from our own loopback 0.
|
|
0:35:38
|
But if I were to test this without the source being the loopack 0,
|
|
0:35:42
|
the destination does not have a route back to where I'm originating the traffic from.
|
|
0:35:47
|
So, this means that the packets are gonna get to the destination
|
|
0:35:51
|
but then they will not be able to reply.
|
|
0:35:56
|
So, the key point here, to make sure that when you're doing your connectivity testing,
|
|
0:36:00
|
it has to be sourced from some interface that you're actually advertising into the process.
|
|
0:36:09
|
Now, also within the scope of the lab exam,
|
|
0:36:12
|
sometimes you can see strange desings where maybe a running IGP and BGP
|
|
0:36:17
|
between the neighbors at the same time.
|
|
0:36:19
|
In a real world design, that's generally not gonna happen.
|
|
0:36:23
|
But we could have a case here within the lab exam just for testing.
|
|
0:36:27
|
That's the design.
|
|
0:36:28
|
Where maybe if we look at our diagram or maybe BB2
|
|
0:36:34
|
is learning our internal routes from the RIP Process or fromthe OSPF Process.
|
|
0:36:39
|
Which in this case is, in that case, as long as they have a route back to where I'm sourcing the traffic from.
|
|
0:36:45
|
Then I should be able to do that connectivity test.
|
|
0:36:49
|
But the keypoint to remember here is that with IP routing,
|
|
0:36:52
|
the communication is bi-directional.
|
|
0:36:55
|
So, just because I have a route to you,
|
|
0:36:58
|
it doesn't mean that you have a route back to me.
|
|
0:37:02
|
Where in the case of the Layer 2 switching we saw,
|
|
0:37:05
|
with Spanning Tree, the route on the way there always has to be the same as the route on the way back.
|
|
0:37:11
|
Where the Layer 2 switching path on the way there is the exact same on the way back.
|
|
0:37:15
|
But with IP routing, it can be a synchronous.
|
|
0:37:17
|
My route to you is completely independent of your route back to me.
|
|
0:37:28
|
So, now on, let's say router 3 who's in a different autonomous system,
|
|
0:37:34
|
let's look at the end result of this, if we look at the Show IP BGP,
|
|
0:37:43
|
we see now the prefixes that were originated by router 5,
|
|
0:37:47
|
which are 150.28.5.0, 150.28.8.0 and 150.28.10.0.
|
|
0:37:55
|
We see the origin code is incomplete. For all of these, it has the question mark.
|
|
0:38:01
|
Some of these have a med value set. Some of them do not.
|
|
0:38:06
|
Ultimately depends on where we're learning the prefix from.
|
|
0:38:09
|
Whether it's the direct neighbor that is originating the route
|
|
0:38:13
|
or whether it's through some other autonomous system.
|
|
0:38:17
|
So, if I were to look at the details for the prefix 150.28.10.0/24,
|
|
0:38:25
|
it says, "There's three possible paths. The one in the middle is the best path.
|
|
0:38:30
|
This one is being learned directly from router 5."
|
|
0:38:33
|
And it has a metric value of 158720.
|
|
0:38:39
|
Whereas the route that is being learned from router 2 and the route that is being learned from router 1,
|
|
0:38:44
|
since these prefixes are passing through another autonomous system,
|
|
0:38:48
|
the med value is being stripped from the advertisement.
|
|
0:38:52
|
Because again, the key point is that the med value is a non-transit of attribute.
|
|
0:38:56
|
WHich means it's gonna go to 1 AS. But then not multiple ASs beyond that.
|
|
0:39:03
|
If we did want to implement some policy for med then we would have to manually specify that
|
|
0:39:07
|
either as the prefixes are being advertised out or as the prefixes being received inbound.
|
|
0:39:13
|
Now, another thing we'll spend a bunch of time today going over is the logic of the BGP regular expressions.
|
|
0:39:19
|
How we can use this to filter the output of the BGP show commands.
|
|
0:39:22
|
How we can use it for the AS path access list and also for the expanded community lists.
|
|
0:39:29
|
But based on the output of Show IP BGP here,
|
|
0:39:32
|
we can see that one common attribute for all of these redistributed routes
|
|
0:39:37
|
is that they have the origin code of incomplete after the autonomous system path.
|
|
0:39:45
|
So, if I wanted to see all of the routes that have the origin incomplete,
|
|
0:39:49
|
I could say Show IP BGP,
|
|
0:39:53
|
then include the question mark.
|
|
0:39:57
|
But the problem is we know the question mark is used for the contact sensitive help in the actual IOS parser.
|
|
0:40:04
|
So, for anytime you'e trying to use a question mark in a regexp,
|
|
0:40:07
|
you need to issue the escape sequence first, which is control V.
|
|
0:40:14
|
So, now I can say Control V then the question mark.
|
|
0:40:18
|
Okay, also notice, it says that there's nothing following the question, so it's fairly the compile the regular expression.
|
|
0:40:25
|
We'll see that the actual question mark is a special character inside the regexp.
|
|
0:40:31
|
Where essentially it means true or false, or a 0 or 1 instance.
|
|
0:40:36
|
Where I would wanna say here,
|
|
0:40:37
|
Show IP BGP and include the question mark but I wanna match this literal character.
|
|
0:40:43
|
So, I would need to escape this first, which is a backslash.
|
|
0:40:50
|
So, then this is gonna show me all of the prefixes that have the origin code of incomplete.
|
|
0:40:55
|
So, again, our first two examples here, pretty straightforward with the network statement.
|
|
0:40:59
|
Only requirement is that we have an exact match in the routing table
|
|
0:41:03
|
for whatever prefix we're specifying.
|
|
0:41:05
|
If we don't specify the mask keyword, then it's gonna assume that the route is a classful mask.
|
|
0:41:12
|
With the redistribution, everything is gonna be included by default with the exception of the OSPF externals.
|
|
0:41:18
|
So, we would need to say, Redistribute OSPF 1 or whatever the process ID
|
|
0:41:22
|
followed by match internal-external.
|
|
0:41:26
|
We could also do this inside of a route-map.
|
|
0:41:28
|
Where we're matching some specific prefix.
|
|
0:41:31
|
We could also say match the metric type.
|
|
0:41:35
|
Which would be the metric type E1, E2, N1 or N2.
|
|
0:41:39
|
Then that will allow us to redistribute that particular prefix into the BGP process.
|
