[music]
Okay, so next is going to be redistribution in IPv6.
We'll again be using our-- this will probably be one of the last
times we use this topology.
I'm going to be moving over to a different one for doing tunneling, because
we already have IPv6 running everywhere here, so there's
not really any place to tunnel.
But what we're going to do is we'll use this topology here for our
redistribution, and I'm not going to get real fancy with it.
We're just going to look at some of the little caveats with redistribution.
This is, of course, a whole other topic.
INE has several other videos out there just on the topic of redistribution,
so we're not going to get into a whole bunch of details such as loop
prevention, and all that kind of stuff, because it is fundamentally
the same as IPv4 redistribution. You still have to account for possible loops,
we can still use route tagging, you can use distribute lists,
you can use prefix lists, tags, all the different methods of controlling loops
are the same. The only thing that we really need to worry about
is a couple of little caveats, and then,
of course, we have to also get back to the OSPF database and look
at the changes to the externals, although that's not going to take a long time.
Now, one of the fundamental things you really, really, really
need to watch for is that the connected interfaces are not automatically
redistributed as they are in IPv4. Now, if you're not really good with redistribution,
let me just explain quickly what we mean by that.
Generally speaking, what's going to happen is,
when you redistribute into a routing protocol it's going to go to that parent protocol.
So I'll throw out an example. Let's say you're redistributing RIP into OSPF.
So you go into OSPF, you say redistribute RIP, you hit Enter.
What the router's essentially going to do-- now obviously the IOS
does not type show commands internally, of course. But essentially what it's going to do,
is say show ip route RIP.
And it's going to look at the routing table and get all the RIP routes.
And it's going to take them, and based on whatever criteria you put
on the redistribution line, or just going with defaults,
it's going to take those routes and it's going to put them into OSPF. Fine, no problem.
But, what about the connected interface that's running RIP?
When it does a show ip route RIP, that route is not going to show up,
because it's not in his routing table from RIP. It's in his routing table as connected,
because it's his interface. In IPv4, it'll look at that and go, well,
you said redistribute RIP, and this interface is running RIP. And you know what?
You probably wanted that connected route.
So as long as it's connected to an interface running the redistributed protocol,
it will grab that subnet and bring it along and put it into OSPF.
Now, there's a caveat with that even with IPv4.
And that is, if under the OSPF process you had done your own redistribute
connected and said whatever, then the IOS would look at that and go,
oh, wait a minute, you're redistributing connected interfaces.
Well then, I'm not going to do this automatic
bringing in of connected from the redistributed protocol.
So you would have lost that connected interface in RIP if you had
done the redistribute connected, and run it through a route map as per best practice.
Now, if you had literally just said, redistribute connected, under OSPF I mean,
you would have been fine anyway. You would have gotten all of the connected interfaces.
But if you've done it per best practice,
and you've run it through a route map, you better make sure you include
that other interface. So how does all of that relate to IPv6?
IPv6 looks at everything I just said and goes, wait a minute.
David, back up a little bit to where you said,
the router looks at the routing protocol redistribution and says,
well, they probably wanted it. Wait, probably? We have a name for that.
It's called making an assumption.
The router was assuming that you wanted that connected RIP route
just because you said redistribute RIP and it's a connected interface running RIP.
So yes, the router made an assumption.
Truth be told - and this is just my humble little opinion - that's
true and accurate most of the time.
It's a good thing and it's why it's sort of always been that way.
Problem is, assumptions aren't usually good in networking.
We want things to be deterministic.
We want things to be exactly the way they're supposed to be and completely
and totally technically accurate.
Technically, it should not be grabbing those connected interfaces.
That does not happen automatically in IPv6.
Now, can we tell it to exhibit the exact same behavior as IPv4 does?
Yes, we can, and that's one of the caveats we're going to look at in our config here today.
The other piece to this - RIPng acts a little bit interesting here.
It sort of acts like metric transparent, if you're familiar with that from the MPLS world.
I'll show you what I mean when we get there though.
So, on that note, let's hop over and take a look at what we're
going to redistribute today. And like I said, we're not going to redistribute everything.
We'll just do some spot redistribution,
if you will, just so you can see some of the caveats that we're talking about.
So what we're going to start with here is, we're going to start
with doing a redistribution on router 5 and we'll just go from EIGRP
over into the OSPF world and vice versa.
We'll go both ways here with OSPF and EIGRP on router 5. Let's hop over to router 5.
Let me get over to the command line here, on router 5, and we will say--
first thing we're going to say is do show run section router,
because as we were building our routing protocols,
we sort of did a mix and match of how we were running EIGRP and OSPF.
I'm just going to look so we're all on the same page here.
We ran named mode EIGRP on router 5 and then we did legacy ospf ipv6 config.
In other words, we did not do OSPFv3.
So that said, let's start with redistribution into OSPF.
So we will say, ipv6 router ospf 1, redistribute eigrp 100.
And I'm going to start with just hitting Enter, and let's take a look at what happens.
Let's hop over to, say-- router 2 seems like a good candidate because
that's in area 0, and say, do show ipv6 route ospf,
and we should now have an external route - at least one. Of course, we have a couple.
So we have 36, which is of course the subnet up here at the top
between router 3 and 6, so that's to be expected.
We don't have anything for 456. That's to be expected as well,
because remember, the little dots there mean link local only.
There's nothing to advertise. That's literally being treated like a transit network.
We also picked up ipv6 route for router 6's loopback.
Now router 5's loopback, of course, is already in OSPF. At least it's supposed to be.
Yeah there it is, okay. Looking right past it there for a second.
So, router 5's loopback's already in OSPF natively.
So, we pick up 36 in router 6's loopback. But this is exactly what I was talking about.
We don't have anything connected. Now, in this case, it's not probably the best example,
because there's nothing to be connected.
So, to change that, let's go to router 5 - since we've already sort
of looked at his loopback - and say, interface loopback 55,
and I'm going to say, ipv6 address 2001:db8:55::55/128,
and then we'll say-- that should already be in EIGRP at this point.
So, let's go to router 6.
Do show ipv6 unicast-- do show ipv6 route for EIGRP [might work better?].
So he's already learning that 55 network. So, the 55 network is in EIGRP.
But again, if we go to router 2,
not an external route. We don't have the 55 anywhere.
and this is the behavior I was talking about a minute ago in our little intro there.
You're not getting the connected network even though that interface is running EIGRP.
So if I go over to router 5 and I say, do show ipv6 eigrp interfaces,
it's going to cover that 55 loopback I just created.
It's there, it's running EIGRP, but it's not coming along.
Now, we already sort of talked about this. The reason is we need to go back into OSPF,
and this is the caveat that I'm really trying to show you here.
And when you say, Redistribute eigrp 100, you need to say, include connected.
Or you can always, of course, go into OSPF and do your own redistribute connected.
Of course you could still do that.
But if you want it to exhibit the same behavior that IPv4 did by default,
then you have to actually say include connected. And by the way,
you can also-- if you're familiar with the word subnets,
you cannot type that - unknown command, never heard of it.
If you look at the options here there is no choice to do subnets.
That's understood in IPv6, so a couple little caveats there.
Number one, when you're redistributing into OSPF you can set the metric type.
You can always manually set the metric,
run it through a route map, set the tag, these are all things you can do.
The big caveat being include connected, and not using the subnets keyword anymore.
So those are some of the caveats going into OSPF.
And then let's look at what this thing actually creates.
So, do show ipv6 ospf database external self-originated.
So this is the-- these are, I should say, the type 5 LSAs that router 5 is generating.
So, just to revisit the OSPF database here for a second,
these are really, really no different than for OSPF Version 2. It's external,
It's got an advertising router. The sequence checksum length,
obviously, it's an IPv6 prefix and that means we have to give it
the mask and/or prefix length. The metric type, the actual metric.
The thing that's missing, and I mentioned this in a lesson when we were
going through OSPF, the thing that's missing is the forwarding address.
There is no need - it wouldn't even work - to expose the forwarding address
in IPv6, because the forwarding address is always a link local address.
Now just like IPv4 and OSPF version 2, if I went to a router in another area
and said do show ip-- not ip. Do show ipv6 ospf database external,
the type 5 LSAs are, just like version 2,
passed through the entire network completely unchanged. So here's your external.
Routing bit is set, which is really funny because it's from the advertising
router, 10.5.5.5. Yet if I were to say do show ipv6 ospf database router
for 10.5.5.5, he's going to have nothing.
We can't even filter it that way, but we could say-- we could just hit Enter.
These are the type 1 LSAs, and this is for 10.1.1.1,
there's router 2, router 3, Router 4, and of course switch 4 somewhere.
There it is, switch 4, and that's it. I don't have a type 1 LSA for router 5.
I'm sure - if you're already familiar with OSPF at all - you know
that this is where the type 4 LSA comes in to support how we're
going to get to this external router.
We have this router here, 10.5.5.5, that's advertising himself effectively
as an ASBR, but how do I get to him?
That's where we have to say show me the database for inter-area router.
Now I'll have a type 4 LSA.
This is basically nothing more than the ABR, router 4, telling me,
hey, when you need to get to that ASBR, router 5, come to me.
This is the type 4. It's almost exactly like a type 3.
The real difference between a type 3 and a type 4 is a type 3 is
advertising a destination prefix as being available through the ABR,
and a type 4 is advertising an ASBR as being available through an ABR.
You can also, by the way, see this with a do show ipv6 ospf borders.
This will show you all of the routers that we know of that
are ABRs or ASBRs. And the cool thing is, it'll actually show you here,
that's an ABR, that's an ASBR, and if it's both, by the way, there'll
just be a slash and it'll say ABR/ASBR.
Then you can also see if you learned this intra or inter-area.
So the lowercase versus uppercase i in this first column right here.
So these two characters right here are telling you, essentially,
did you learn about that router from a type 1,
or did you learn about that router from a type 4.
That's essentially what that means right there.
Did you learn about this from within your own area or via a type 4
LSA from another area, okay?
So again, type 4s and 5s, not fundamentally different in OSPF from IP version 4.
That pretty much wraps up OSPF. Let's hop over to router 5 again.
Let's say router eigrp ipv6. Address family ipv6 unicast for AS 100, topology base.
Redistribute OSPF 1. And then like always, if I just hit Enter,
I'm not going to advertise anything. If I go to router 6 and say, do show ip route eigrp,
Nothing, right? And if I say, do show ipv6 eigrp topology...
Okay? He's learning them-- actually he's not. I'm sorry. These are the ones he's creating.
So 36 and 6 he's putting in. So, he's not learning them, nothing.
That's of course because you have to put in a seed metric.
So a lot of people go, okay, fine. So, metric, bandwidth delay reliability load mtu,
they're all ones. There we go. And with IPv4, and more importantly with 32-bit metrics,
this was okay. But now, going to be a little bit of a problem.
If I go up to router 6 and I look at the topology,
look at the feasible distance.
Little bit of a problem.
Now, with IPv6, it'll actually take that.
Because IPv6 routing table supports larger metrics than the IPv4 routing table.
So it'll actually take it with IPv6, but really, 4.2 billion for your metric?
I don't think that's really what you're after. I really recommend staying away from it.
If this was IPv4, this wouldn't even work.
It would come up and say that the metric is-- I think what it says
is metric infinity, whatever, okay? This technically works with IPv6, but man,
seriously, I recommend not doing it. Make it something reasonable.
Metric - I don't care - 1500.
You still don't want it to be a good metric, because with redistribution,
it's pretty much best practice to keep external routes at a worse
metric than internal routes.
There's tons of other ways - I refer to that as layering - but there's
several different ways to solve redistribution, loop problems and such.
But making external routes less favorable than internal routes,
either through admin distance, through metric, through a combination of them -
there's a bunch of ways, but one of them is to keep the metric not so favorable.
But at least 1.5 megs is better than 1K.
It's still going to be a lot more favorable, and instead of these
ridiculous numbers like this, you're going to get something at least
a little more reasonable. It's still not great but it's considerably shorter.
Really, it doesn't matter. The point is you have to provide a seed metric.
I would just, with named mode, really avoid the 1.1.1.1. You have to for IPv4.
For ipv6, it just gets extraordinarily ugly if you don't.
Other than that, there's your routes. There's your routes.
Something else you could possibly do here is, on router 5-- I've got all these
loopbacks coming in. Loopback for 1, 2, 3, switch 4 - I got a lot of loopbacks.
I could go to router 5 and I could say, af-interface g0/0.-- no, not on this guy.
Sorry. Fa0/0.456,
summary-address 2001:db8:100:100::/64.
I could create a summary address,
go back to router 6.
And first off, we get rid of all the loopbacks,
and now we're advertising just the loopback subnet range in as a /64.
The other thing to note is, just like with IPv4,
and you can do this in IPv4 as well, as soon as you create a summary address
this now becomes an internal route. That's because, technically
router 5 is originating the route, not redistributing it.
He's redistributing the routes into the EIGRP topology table but
then when he goes to send them out that interface and you have the summary address,
he goes, oh, so suppress those and generate this /64.
The key is, and generate the /64. He's originating it.
Why would it be external if he's originating it?
When it goes through that process it does make it an internal route again,
which can sometimes throw people a little bit there.
It can also maybe mess with your admin distance a little bit too.
So you got to be a little bit careful if you were bringing a summary
in from say-- you were summarizing in OSPF and EIGRP,
but you wanted to follow the OSPF path,
you might have to do some admin distance manipulation here.
Because otherwise, it's going to follow EIGRP with an admin distance of 90
over OSPF with an admin distance of 110.
So just again some interesting little things you have to watch out for there.
Other than that, that's redistribution into EIGRP.
Not really too much to do there.
Let's go down-- and let me switch back to our diagram here real quick for you.
What we're going to do next--
I don't even have to go both ways because I'm not even interested
in full connectivity, I'm just trying to show you some caveats and
things to watch out for. So we saw the type 4s, we saw the type 5s in OSPF.
In EIGRP, we saw what you have to mess with, with the metric.
I'm not even going to redistribute into BGP.
We're going to do a lot of that in the MPLS section
when we're talking about transition mechanisms and tunneling.
So, we're going to get back to that. I'm not even going to bother doing it right now.
There's not really too much to be concerned with anyway.
It's sort of like redistributing in anything else.
What we will do, just so you can see a little bit of a caveat here,
Is we'll redistribute on router 4, into the RIP process.
Because we've done redistribution into OSPF - no big deal.
Redistribution into EIGRP, into OSPF,
and now redistribution into RIP on router 4.
So let's switch back over here to the command line,
go to router 4, and we're going to-- I'm going to have to look at the config,
because I don't remember. Do show ipv6 protocol. I think we called it RIPv3, yes we did.
So, ipv6 router rip RIPv3, redistribute ospf 1.
And on this one, I'm leaving the metric off on purpose, because I want you to see this.
If you go to Switch 1 now, who's right below router 4 there,
do show IPv6 route-- I could filter it with RIP. You know what? I will.
I was going to say, he doesn't really have anything else,
but you do have all those local and connected, so I'll just filter it on RIP.
Here we go. So, I think the first most interesting thing, is he actually has some routes.
Like, for example, the ::3.
That is an OSPF route. So is ::2.
Now, 52, that's native RIP.
That's over between switch 2 and router 5 if you're looking at the diagram.
41-- sorry, not 41. What was the other one? Here.
8 is switch 2's loopback so that's native, but there's another one coming from OSPF.
We already have some networks here coming from OSPF.
But what's interesting is we don't have everything. We don't have the EIGRP routes.
We don't have router 1's loopback.
There's a lot of things we don't have, and the answer is simply here.
If you say do debug ipv6 rip, and we watch for an update to come in
- and of course RIP being the speed demon it is, it could take a second here.
That's him sending, sending...
He just sent out all of his updates. We've got to wait for a receive though.
There we go. We'll turn off the debugging, give it a second to stabilize here. Okay.
And we can already see what's happening right here,
coming in on VLAN 41 from router 4. Look at all those prefixes.
Yeah, there's 41, there's 3's loopback,
there's 2's loopback, switch 4's loopback. And notice what they all have in common,
metric 1, metric 1, metric 1, metric 1. But, look, I'm getting the DMVPN cloud 123,
I'm getting the host DMVPN route from router 1.
Router 1's loopback, router 6's loopback coming all the way from EIGRP over there,
there's that 55 network coming in from router 5,
VLAN 36 between router 3 and 6 coming from EIGRP - I'm receiving everything.
But the metric on all of them is 16.
And the reason is, if you were to go look at the OSPF environment for
the DMVPN, the costs are like 1000, and all the routes being redistributed
into OSPF from EIGRP all have a metric of 20 by default. Well, I got news for you.
20 doesn't fit into a RIP hop count of 15, and 1000 certainly doesn't.
So what do you end up with? Well, here it is.
You end up with routes being learned but an invalid metric.
Now, th00 I'm getting the host DMVPN route from router 1. Router 1's loop back. Router 6's loop back. Coming all the way from EIGRP over there. Okay. There's that 55 network coming in from router 5. VLAN 36 between router 3 and 6 coming from EIGRP. I'm receiving everything. But the metric on all of them is 16. And the reason is if you were to go look at the OSPF environment for the DMVPN, the costs are like 1,000. And all the routes being redistributed into OSPF from EIGRP all have a metric of 20 by default. Well, I got news for you. 20 doesn't fit into a RIP hop count of 15. And 1,000 certainly doesn't. So what do you end up with? Well, here it is. You end up with routes being learned but unenvalid metric. Okay. Now, the interesting thing is IPV4 won't even do this. RIP on IPV4 basically says if I don't have a seed metric, then I'm not redistributing but this is what I was talking about with the last bullet point on the slide there that RIPNG exhibits a metric transparent behavior. It's trying to take the metric from OSPF and put it in the RIP. Now, for some routes, that worked. Some routes, that was okay. Other routes? Not so much. So really, the moral of the story is can you redistribute without a metric? I don't know, sort of. If you're careful, sure. But again, we'll bring them in as a relatively bad metric. But as long as you put a metric on and then when we receive the updates and I have the debugging off right now, let's see if they showed up already. Yeah, we already got them all. So it already updated. Notice they all have a metric of 10 now. All the ones coming in from OSPF, which is to be perfectly expected. So again, these are just some of the caveats you have to watch out for with redistribution with IPV6. So just to summarize, you don't forget the include connected part. That can really throw you. Rip, the way it handles the seed metric is a little weird. And if you're doing maimed mode in the IGRP, I would recommend staying away from the metric of 1111. And like I said earlier, as far as the BGP goes, it's not really any different. It's exactly the same as IPV4, but we will be doing some as we move into tunneling in the next sections. Thank you. Thank you.