[music]
Let's jump in and start with the straightforward - IPv6 over IPv6 since
that is, of course, our main topic for the course.
Let's just go ahead and jump right over the command line here.
That's basically what we're going to be doing, so hopefully you have
the diagram handy.
If not, you'll want to get it handy.
I may switch back and forth to it for reference as we go as well,
but this would be a good place to have our diagram probably printed out,
or available on another screen, or something you can switch to.
Again, we're going to be starting off here between--
we'll start with Router 3 to Switch 3.
As we go through the upcoming lessons here with different combinations.
I will rebuild it each time.
We'll be starting with no BGP in each lesson.
That way we can see each one how to build it and that way gives us the
opportunity to do a couple of more combinations of things as well.
On Router 3, we're going to say router bgp 100 and we're going to say
address-family ipv6 unicast.
Then we're going to say neighbor 2001:DB8:100:39::9 remote as_300.
That's just the easiest way to jump in and get started.
Couple of things to note, BGP-- and you have to realize it inside of a
company the size of Cisco and such, there's different teams that code
different parts and since that's the case.
Then things like this happen.
Which is sort of fun.
If we look at the show run for the section BGP, something to note is, what we did,
is we went into router BGP 100.
And we went right into address-family IPv6, and put in the neighbor with the
remote-as statement.
Well, the code looked at that and said, Oh, I see what you're trying to do
what you meant to do, is you meant to put the neighbor
statement up here under global BGP mode, and you meant to turn it off for IPv4,
because you didn't turn it on in address-family IPv4,
and you meant to activate it in IPv6.
What sort of nice about this code is - and again most versions of IOS will do
this for you - it just moves the stuff around to where it needs to be,
so my whole thing with IPv6, go right into address-family IPv6 and
start putting in your commands.
As you do this, what you're going to end up with,
is the code moving the stuff to where it should be.
Moving forward, let's go ahead and get our neighbor up.
By the way, if you take a look at do show ipv6 tcp--
sorry, you don't actually have to say that on this do show tcp brief all.
You can see that he's already listening on TCP port 179,
and he's listening specifically for traffic coming from that neighbor's
IPv6 address on any port to any interface on this router port 179.
So he's already listening for the session over IPv6.
And the reason of course is because we put in an IPv6 address as our
neighbor statement.
So let's go over to switch 3, and we'll do the same basic thing.
So router bgp 300 and address-family IPv6 unicast and neighbor 2001
DB8:100:39::3 remote-as 100 and that actually should bring the neighbor
relationship up as long as everything is correct,
because we do have direct connectivity.
This is of course the directly connected interfaces, I'm peering on physicals.
So then you say, do show bgp ipv6 summary.
It'll probably yell at me.
Yeah, it did.
You're not suppose to use-- you're supposed to start putting in
unicast or multicast now on these commands too.
I notice it's yelling at me.
Use the show bgp ipv6 unicast.
Oh okay, I'm so sorry.
So let's see if we can prevent getting yelled at.
Do show bgp ipv6 unicast summary.
See now it doesn't yell.
But the point is is our neighbor is up, it's been up for 36 seconds at this point.
No routes sent or receive, because I'm not injecting anything into BGP.
If I were just to say, show bgp ipv6 unicast.
There's nothing in our table and that's not going to do us much good.
So I'm going to go ahead and inject switch 3's loopback here, and of course,
I could redistribute connected.
There's a bunch of ways I could do this.
I'm just going to bring it in with a network statement.
So network 2001 DB8:100:100::9/128.
I don't know how an i snuck in there.
It's not exactly hex.
Do show bgp ipv6 unicast and there you go, we're injecting our network.
And as long as we've done our job correctly, this should show up on Router 3 now.
Do show bgp ipv6 unicast.
There we go.
So just from the basics, just getting started here, sending IPv6 routes over an IPv6
session in BGP is really just as simple as that.
In fact, I should really be able to ping it - no problem.
The other thing to note too, is a lot of people look at this, and they're like,
oh but the next hop is 39.9 - what about that whole link local thing.
Well, do show ipv6 route bgp.
Notice the next hop in the BGP table is the actual physical address of the
next device.
However, when BGP says, do show ipv6 cef for that address
notice that it's attached to FA0/1.
So when he does his recursive look up he knows that it's supposed to go to the
link local address of the neighbor.
So it's already done the recursive look up when it puts the BGP route into
the routing table.
It already knows to route that interface to the link local address.
Now, in a minute we're going to see where this is not always the case but
let's take a look at that as we move forward.
First, just to show you if you are familiar with BGP you got to really be
careful here with some of your older commands like, do show IP BGP, nothing.
Do show IP BGP summary, nothing.
Do show IP BGP neighbors, nothing.
Because we're not doing the IPv4 address-family right now.
We've only turned on address-family IPv6 unicast so the equivalent of these,
I've already shown you two of them.
The other one of course would be do show bgp ipv6 unicast neighbors.
And then you can see that the neighbors are up, and we don't need to look at this
whole thing.
What we do need to see though is this part right here.
So address-family, ipv6 unicast advertised and received.
And of course, in order for us to agree on an address family we're exchanging between
BGP neighbors, then you have to have advertised it.
Meaning saying you're willing to accept that address-family and you have
to be willing to send it or send it and receive it.
You have to do both.
So that's just real simple basic.
From here on out, it's just BGP.
All the same things apply that apply on IPv4.
You can do all the same things, same route manipulation.
We're going to look at some of that stuff moving forward,
but in the meantime I'm going to bring up a BGP session with Router 6 as well.
But Router 6 I want to do a little bit differently.
On Router 6 I'm going to say neighbor FE80::6 and then we have to
say % VLAN 69 and it would probably help if I actually put the remote-as on there.
That's your mode AS 100 and that's fine.
I want you to see this, I did this one on purpose first meaning doing Switch 3 before
Router 6.
This particular set of equipment that I'm operating this whole thing on for
these lessons this is running on physical equipment and for some of the
features that I use for some other courses and such,
we need some advanced code on these and it is rather advanced code for this
hardware platform, and it does have a few minor issues
and you're about to see one of them - that's why I'm bringing it up.
If I say, router bgp 100 address-family ipv6 unicast neighbor fe80::9%gigabit
Ethernet 0/0.-- actually that's gigabit 0/1 remote 300 - there we go.
It actually performs a traceback.
It's actually sort of interesting - IPv6 is address Rs - no,
no it's not code for link local address with wrong table ID.
Okay. This is clearly and error.
Like I said, other code and that's why I wanted to show you Switch 3 first.
Other code does not do this.
It's fine.
This is how you peer using link local addresses.
For some reason this particular code on this particular platform,
nothing to lose sleep over is this not production code in anyway.
You would never be using this in production.
Cisco refers to it as experimental code.
It's not like internal or anything you can technically download it through CCO
it just doesn't show up on the normal download page for this platform.
I don't want to go so far as to say beta because it's not it's experimental
but point is this, it doesn't really matter.
It's really a whole lot of explanation just to say, the neighbor's up.
So, it can yell.
It can scream.
It can do its little traceback.
I like to just say it's throwing a temper tantrum over here.
The fact of the matter is, it's up.
And if I said do show BGP IPv6 unicast, he's got the route.
So it's working.
Everything's fine, okay.
Notice though, he is listing the next hop directly as
the link local address there now.
Which, you know, sort of saves a little bit I guess.
When you get to the routing table, and it's just already set to the link local.
Now, he does of course still have to look up the interface and all that,
for the recursive lookup.
But that's basically IPv6 over IPv6, using link local addresses.
So the way you do it, is you put in, again, the remote neighbor's address and then
the % then remember case sensitive and the egress interface
written out in it's entirety, you can't say GI0/1 we've been through
this in a previous lesson.
But that's how you do it.
Now again this particular code yells at you it's nothing to worry about.
Normal production level code like this does not and it's fine,
it just comes right up.
One other quick thing to note there are some versions of code out there
usually the older stuff that the way you did was you said,
neighbor FE80::6 remote AS 100.
Then you would say neighbor FE80::6 update source in this case VLAN 69 or
update source gigabit 0/1 and I think this code actually still supports that.
I haven't actually tried it on this particular code.
It wouldn't take much to do it here.
It should go down neighbor fe80::6 remote 100, no, this is the switch, up vlan 69.
That's how you did it on some older versions of code.
I'm not even sure if this version of code will even do it that way anymore.
That's sort of like a legacy config, so can't give up quite yet though
because the other side may not have given up yet.
Peer closed the session, now he did realize it was down.
So I don't think it's going to come up.
Do show BGP IPv6 unicast summary.
Yeah, current state is active for that neighbor which basically means he
thinks he's trying but he's not really doing it.
Do show TCP brief all.
He says he's listening to it.
It's just not going to work, that's fine.
We'll just say no to that.
This is it, like I said, this is the new way to do it anyway.
Just to let you know again, if you did have legacy code - if you
had some older code on some devices - you may have to do it with the update
source method in order to get this to work.
While we're waiting for that to come back up - and again,
we may have to wait for some stuff to time out since it was already trying.
Let's take a look here real quick - so it's listening right, it's idle I
got to give him a second to go active on it.
Here we go, that should come up.
Anyway while we're waiting for that I'm going to run a little bit of iBGP
over here so let's go over to Router 3 and I want to say--
now for this guy we really sort of have no choice but to run over link
local because that's all I have on VLAN 344.
I'm going to run this down to Router 4.
So I'm going to say neighbor FE80::4% FastEthernet0/0.
344 remote AS 100 and traceback thank you.
At least it's predictable, right?
Router 4, router bgp 100 address family ipv6 unicast 4 as 100 -
I don't know why I typed that, that's like a EIGRP command that I was
trying to type there - neighbor fe80::3 % and traceback and up, see?
Oh my goodness I'm going to crash.
Oh wait, no I'm up - it's just funny.
Do show bgp ipv6 unicast.
I just want to point out that the next hop is going to be kept to global address.
One of the things that gets a little entertaining - and we could do this too
- let's see with link local only-- to show the other example,
let's bring up between 5 and 6.
This is just sending the route straight through - no big deal, nothing to really to--
now we have a little bit of a problem of course,
because that address is not reachable.
If I were to say, do show bgp ipv6 unicast-- and the reason we know by the way is
that it's not set as best, so if we were to take a look at that particular network,
the next hop is inaccessible.
This is because we're not running any routing protocols anywhere, advertising
this in anywhere so the typical fix to this would be to go to Router 3.
I'm just trying to show you how this is like regular BGP.
It's really not any different and I'm just going to say next-hop-self.
Tell him to change the next hop to his own address, he's going to yell at me again.
Should clear it if not we'll reset the connection.
A little more concerned that switch 3 and Router 6 haven't come back up.
That would be why.
It never took out the other one - it's still in there wrong.
That's entertaining.
Let's kill it completely.
That should get completely rid of it.
Okay, better.
Let's try this again - neighbor fe80::6%vlan69.
Let's see if 3 has updated 4 yet.
There we go, look at that - just fixing everything at once.
Now we have a good next hop.
I can't really ping that one, because the way it is right now,
switch 3 has no idea how to get back to Router 4, so pings, and traces,
and stuff at this point would not really be useful.
But the fact of the matter is, we have the route, it's chosen as best,
the next hop has been changed to the next link local address using the next hop self.
Something else I want to show you though - sort of the opposite of what
we just did on Router 3 and 4, where 3 was peered on physicals and
therefore when he was trying to send the update he was leaving the next hop
alone like BGP normally does with iBGP remember this is a eBGP learned route
being sent to an iBGP neighbor and he left the next hop alone which is the
default behavior.
That's all great.
Where things get a little interesting is if I go to Router 6 and say do
show BGP IPv6 unicast.
His next hop is already a link local address so then what's going to happen
when if I say neighbor FE08::5%gigabitethernet0/0.
456 remote AS 100 I'm going to send this to Router 5 now.
By the way as we're typing all these in just be glad it's not like 10 gigabit
Ethernet and stuff like that - its name's a little long here.
Router bgp 100.
And just to show you, by the way, I said I wasn't really going to go
there in the previous lesson when I was sort of introducing this, but I will anyway.
You can also say, no bgp ipv4-- oops, oh I think I set-- I didn't even say it,
it's default, sorry.
No bgp default ipv4 unicast, and what that does is say,
don't even bother negotiating IPv4 address-family with this guy, with anybody really,
because I'm not running it.
I just want to show you, that if I then say, address-family ipv6 unicast,
like we did with the other guys and said neighbor FE80::6 fastethernet0/0.
456 remote AS 100 traceback up go ahead, come on you can do it.
Here we go.
Do show BGP IPv6 unicast.
Oh hey take your time there.
Meanwhile do show run section BGP.
I just want to show you that it doesn't put the no activate line under
address-family IPv4 anymore because that's not the default address-family anymore.
Oops. Notice I'm not getting anything here let's take a look.
Do debug IP, do debug BGP IPv6 unicast update.
Let's see what we're getting.
Do clear BGP IPv6 unicast * in.
Do a soft reset in, oh look what's happening.
So we receive it, receive an update about that
information denied due to martian multi protocol next hop reachability.
Yeah he doesn't like the next hop. Why?
Because it doesn't know what to set the next hop to.
Remember, normal iBGP behavior would be to send the next hop through unchanged.
The problem is - think this through for a minute - what next hop does
Router 6 have on the actual route?
Fe80::9.
What good would it do to send a link local next hop downstream to another
router who doesn't have anything set on it at all--
he has no idea how to get to fe80::9.
In fact, he would think that that was locally connected to him,
which, if you look at our diagram, it's certainly not.
Instead he goes, well I don't know what to set it to,
so I guess I'll just set it to nothing.
Router 5 gets that and goes nothing, okay. That's a martian.
Martian is what we use to call I guess foreign, unknown, unwanted addresses.
I'm sure you guys on your networks probably have a list of networks on
your outside BGP sessions or whatever if you're running it that you don't allow in.
Lately the more common term you hear for that is bogan.
Bogan, martian same thing basically stuff we don't want or don't know how
to deal with or whatever.
So this is basically his way of saying I have no idea what this next hop of
:: is supposed to mean.
I can't follow, theoretically I guess that would be a
default to IPv6 and he's going I can't do that.
So no. No good, denied.
Doesn't show up in the BGP table - nothing at all.
I'm just trying to show you that the fix for this, by the way,
is going to be the same.
That neighbor-- and you just say, next-hop-self - let him set it to his own address.
Let him resend it.
Router 5 should get it - let's just give it a second here.
You always know you're in good shape when you see the debug go by and he
actually installs-- he actually calls to the install route
process when he receives the update.
I'm not patient, this has about 10 more seconds before
I clear it - especially since the command's right up there in my history anyway.
We're going to force it, here we go.
Like I said, always a good process when it calls the revise route process,
and says installing the route into the routing table.
Now he likes it because the next hop he received is FE80::6.
So from a BGP perspective there's not really that much to running IPv6 over IPv6.
It gets a little trickier if you want to use link local only address and the
main reason I spent a little bit of time on this is that may end up being a
rather common thing to do.
We mentioned back in the introduction lesson that link locals remove the need
to have globally routable addresses on our LAN links.
That being the case it might very well be possible you're going to be peering
BGP over that.
So being able to peer BGP on link local is I think significantly
important and that's again the big thing and you're going to see a trend
here as we go through the next couple lessons.
The big trick with BGP and IPv6, is watching that next hop.
That next hop becomes critical.
When it's IPv6 over IPv6, the issue comes in to the link local addressing.
That's where the problem comes in.
Now remember, when we were over on Router 4 getting the routes down from Router 3,
on VLAN 344.
Technically, there was nothing wrong with this route.
That could have been fine.
So I'm just pointing out that if you're using global addresses,
for your nthe problem comes in. Now remember when we were over on router four getting the routes down from router three on VLAN 344 technically there was nothing wrong with this route. That could have been fine. So I'm just pointing out that if you're using global addresses for your next hops and for your peering that you don't really have a problem. Remember the problem with this one wasn't that the route was being formatted wrong, whether the route was being denied or thrown away. No, no, no. The only problem was we don't have a route to get to the next hop. Well I could have given it a route to get to the next hop. Just to show you that this would have worked normally and we'll wrap up with this here. If I went back to router five, if I go back to router three and I take off the next hop self. Go back to router four and clear it. Okay. It goes back to unusable but with a global address. Technically I could just go to router three and say redistribute connected. Normally I would want to do a route map and filter it and all that. I don't even have to do that. I'll just say redistribute connected. I'm going to end up with a whole bunch of stuff that I don't want. And I just did that under BGP and I did not want to do that. Sorry. Can use BGP to get to a BGP next hop. That's a logic problem. I needed to say and on router three I forget how I'm running it. Do you sure run section BGP? It's actually LSPF I'm looking for. And so on this one we ran IPv6. So we have to say IPv6 router. Redistribute connected. There we go. Router four should now get that route through OSPF. And it should become reachable. There we go. Soon as we get the next hop information from OSPF, then BGP can use it. So again I just wanted to point out it's not like I don't want anybody to come out thinking oh you always have to do next hop self with IPv6 or something like that. No, it's just that our external network was not being brought into the routing process. So you have typical next hop reachability problems just like you would in IPv4. So at the end of the day, again running IPv6 over an IPv6 session with BGP is really no different than running IPv4 over IPv4 with BGP.