|
0:00:14
|
The last dynamic routing protocol that we're going to look at here
|
|
0:00:16
|
with IPv6 is BGP.
|
|
0:00:20
|
Now BGP for use with IPv6 is defined in RFC 2545
|
|
0:00:26
|
and that it includes its multiprotocol extensions.
|
|
0:00:30
|
We'll see the logic of this is fairly similar to what we
|
|
0:00:33
|
saw up to this point with using multiprotocol BGP
|
|
0:00:36
|
for the purposes of MPLS routing.
|
|
0:00:40
|
Now one thing that's kind of interesting about how IPv6
|
|
0:00:44
|
works with BGP is that the actual transport of the BGP
|
|
0:00:48
|
session and the advertisement of the network layer reachability information
|
|
0:00:53
|
are technically two unrelated processes.
|
|
0:00:57
|
So what this means is that the routers can peer
|
|
0:01:00
|
with either IPv4 or IPv6 as the Layer 3 protocol
|
|
0:01:07
|
and then independently advertise both IPv4
|
|
0:01:11
|
unicast, IPv6 unicast, IPv4 multicast, IPv6 multicast,
|
|
0:01:16
|
VPNv4, VPNv6 independent of what the transport is.
|
|
0:01:23
|
Now the only functional implication of this is that if the BGP transport
|
|
0:01:27
|
is using IP version 4, we need to make sure
|
|
0:01:32
|
that in the data plane, we are pointing at the correct
|
|
0:01:36
|
next hop value for the actual IPv6 destination.
|
|
0:01:42
|
So we're going to look at this both ways on the command line
|
|
0:01:45
|
where we're establishing the BGP peering using an IPv4
|
|
0:01:49
|
neighbor address, then over this peering we are advertising
|
|
0:01:53
|
IPv6 prefixes, then we'll establish a peering using IPv6
|
|
0:01:58
|
as the transport and advertise IPv6 prefixes
|
|
0:02:03
|
where the actual advertisement of the network layer reachability information
|
|
0:02:06
|
is going to be under the address family IPv6 unicast.
|
|
0:02:11
|
So similar to how we saw before in MPLS
|
|
0:02:15
|
once the transport is up between the neighbors, then we would
|
|
0:02:18
|
activate this particular capability where it is
|
|
0:02:22
|
a negotiated value, so we would want to make sure that
|
|
0:02:25
|
both of the routers on the ends of the peering session
|
|
0:02:28
|
have that particular neighbor activated under the IPv6 unicast address family.
|
|
0:02:36
|
Once we configure the peering, all of the normal BGP rules are going
|
|
0:02:39
|
to apply. This means that for EBGP sessions, we would be using the
|
|
0:02:44
|
autonomous system path for loop prevention.
|
|
0:02:46
|
For IBGP neighbors, we would be using either a full mesh
|
|
0:02:50
|
route reflection or confederation for loop prevention.
|
|
0:02:53
|
The attributes of the BGP updates, things like the
|
|
0:02:58
|
local preference, the AS path, the origin, the Met
|
|
0:03:00
|
those are going to be identical between the IPv4 unicast
|
|
0:03:05
|
network layer reachability information and the IPv6 unicast.
|
|
0:03:10
|
So again, it's one of those cases that if you understand the
|
|
0:03:12
|
IP version 4 counterpart, then you're going to understand
|
|
0:03:16
|
how this works for IPv6
|
|
0:03:18
|
so the main transition point for IPv6 is just to figure out
|
|
0:03:23
|
how the addressing works. Once you can get past that
|
|
0:03:26
|
point, then we can configure basically any of the protocols
|
|
0:03:31
|
with having limited knowledge of their implementation
|
|
0:03:34
|
simply based on us having the understanding of the
|
|
0:03:37
|
IP version 4 counterparts.
|
|
0:03:43
|
So let's take a look at this on the command line
|
|
0:03:47
|
and what we're going to do is configure some peerings
|
|
0:03:51
|
between Router 5 and Router 1
|
|
0:03:55
|
We'll have a peering between Router 1 and Router 5
|
|
0:03:59
|
This is going to be using IPv6 as the transport
|
|
0:04:05
|
then we will peer between Router 1 and Router 6 using
|
|
0:04:09
|
IPv4 as the transport, but still use this to advertise
|
|
0:04:14
|
IPv6 network layer reachability information or basically IPv6 updates.
|
|
0:04:20
|
Now these neighbors could be directly connected
|
|
0:04:23
|
they could be multiple hops away, as long as we have an
|
|
0:04:26
|
IGP that is going to provide the transport, it doesn't really matter
|
|
0:04:29
|
where the neighbors are in the network.
|
|
0:04:38
|
So first let's take a look at Router 5's configuration.
|
|
0:04:42
|
Right now we do have IPv6 reachability
|
|
0:04:47
|
to Router 1's address which is 2001:155:28::1
|
|
0:04:58
|
We also have reachability to their link local address which is
|
|
0:05:02
|
fe80::1
|
|
0:05:04
|
which is reachable out serial 0/0/0
|
|
0:05:10
|
So we could technically do the peering with the link local address
|
|
0:05:15
|
because we do not need the global addresses for
|
|
0:05:17
|
the control plane. If we were doing link local peerings
|
|
0:05:21
|
then that would imply that we have to do it to someone who is directly connected
|
|
0:05:25
|
because link local packets, they cannot be routed between interfaces.
|
|
0:05:31
|
So next let's start the BGP process, we'll say router bgp 5
|
|
0:05:37
|
we have a neighbor that is this address on Router 1
|
|
0:05:44
|
the remote-as is 1
|
|
0:05:49
|
Now without any further configuration beyond this, if we look at the
|
|
0:05:53
|
show run section router bgp
|
|
0:05:59
|
what we would see is that the parameters for this particular neighbor
|
|
0:06:03
|
are actually related to the IP version 4 unicast address family
|
|
0:06:09
|
and not the IPv6 unicast address family
|
|
0:06:14
|
so this means that if we were to go to Router 1 and do an
|
|
0:06:17
|
identical peering on the way back
|
|
0:06:20
|
if we said router bgp 1 neighbor
|
|
0:06:23
|
then we use Router 5's address
|
|
0:06:30
|
who is in remote-as 5
|
|
0:06:37
|
we should eventually see the peering come up
|
|
0:06:39
|
because we already have IP reachability to the neighbors.
|
|
0:06:44
|
If we look at the show ip bgp neighbors
|
|
0:06:49
|
it says that for this particular peer 2001:155:28::5
|
|
0:06:56
|
the neighbor capabilities include the router refresh old and new
|
|
0:07:01
|
and the IPv4 unicast address family.
|
|
0:07:07
|
So it's kind of a strange logic here because we're configuring the
|
|
0:07:10
|
control plane transport using TCP over IPv6
|
|
0:07:18
|
but then we're actually using this to advertise IPv4 routes.
|
|
0:07:24
|
So if I were to go to Router 5
|
|
0:07:26
|
I can now go under the BGP process and say
|
|
0:07:30
|
network 155.28.5.0
|
|
0:07:36
|
with a mask of /24 so a normal advertisement into
|
|
0:07:41
|
IPv4 BGP
|
|
0:07:44
|
If we look at the result of this on Router 1 and
|
|
0:07:46
|
look at the show ip bgp
|
|
0:07:48
|
we see that we're learning the prefix in from Router 5
|
|
0:07:56
|
the problem though is that in the update, the next hop value
|
|
0:08:00
|
is not properly encoded
|
|
0:08:02
|
because it's going over the IPv6 transport and the IPv6
|
|
0:08:08
|
address is not compatible with the IP version 4 address.
|
|
0:08:12
|
So what I could do here I could do kind of a manual
|
|
0:08:15
|
hack in order to fix this. I could create a route map that
|
|
0:08:19
|
says IPv4 BGP in from Router 5
|
|
0:08:25
|
that says set the IP next hop to 155.28.0.5
|
|
0:08:31
|
then under the BGP process for this particular neighbor
|
|
0:08:37
|
who has the IPv6 address
|
|
0:08:39
|
I'm going to apply the route map IPV4 BGP in from Router 5
|
|
0:08:48
|
inbound.
|
|
0:08:56
|
So now if we look at the show ip bgp
|
|
0:09:00
|
we should see that the next hop value is going to change
|
|
0:09:04
|
to the value of the connected interface
|
|
0:09:07
|
so now the route map has been applied.
|
|
0:09:10
|
Now we can see the prefix is installed as a best path
|
|
0:09:13
|
because we do have a route to the next hop.
|
|
0:09:16
|
If we look at the show ip route bgp
|
|
0:09:19
|
we can see that that destination is installed in the routing table.
|
|
0:09:22
|
If we send packets to it ping 155.28.5.5
|
|
0:09:27
|
Router 1 has transport to it.
|
|
0:09:31
|
So it's kind of an odd design here because we're using
|
|
0:09:33
|
again, the same TCP session because the key point to
|
|
0:09:38
|
remember is that the upper layer protocols are not
|
|
0:09:41
|
changing, so things like http for web browsing
|
|
0:09:47
|
or telnet, any standardized TCP application it does not
|
|
0:09:52
|
need to change to run over IPv6 versus IPv4
|
|
0:09:58
|
so it's the same type of logic with BGP here.
|
|
0:10:01
|
We're using TCP for the transport, but TCP
|
|
0:10:06
|
is then being encapsulated inside IPv6 as opposed to IPv4
|
|
0:10:12
|
because BGP is really an application, not necessarily
|
|
0:10:16
|
a routing protocol per se.
|
|
0:10:19
|
It's an application with two jobs: to advertise a prefix
|
|
0:10:23
|
and a next hop value associated with the prefix.
|
|
0:10:32
|
But typically, you would not do this in a design
|
|
0:10:35
|
it doesn't really make sense to use the IPv6 as transport
|
|
0:10:38
|
and then advertise the IPv4 routes over it.
|
|
0:10:42
|
Eventually maybe 10 or 20 years down the road
|
|
0:10:44
|
where the vast majority of the networks are running
|
|
0:10:47
|
IPv6 and IPv4 is then considered legacy
|
|
0:10:51
|
this is kind of like the reverse transition mechanism
|
|
0:10:55
|
where now we're using the IPv6 control plane to advertise the
|
|
0:11:00
|
legacy IPv4 protocols
|
|
0:11:04
|
and we could also do it in the reverse direction.
|
|
0:11:08
|
So now let's go under the BGP process
|
|
0:11:10
|
and the normal configuration here would be to go to the
|
|
0:11:14
|
address family IPv6 unicast
|
|
0:11:18
|
and specify that for this particular neighbor
|
|
0:11:22
|
I want to activate that address family.
|
|
0:11:27
|
So it's basically saying I want to exchange IPv6
|
|
0:11:31
|
prefixes with that particular neighbor over BGP.
|
|
0:11:35
|
Router 5 is going to say the same thing
|
|
0:11:39
|
address family ipv6 unicast
|
|
0:11:43
|
the neighbor is Router 1
|
|
0:11:48
|
and I want to activate them.
|
|
0:12:02
|
So let's look at the full configuration of both Router 1
|
|
0:12:05
|
and 5 let's say show run section router bgp
|
|
0:12:11
|
Router 1 we'll do the same thing show run section router bgp
|
|
0:12:15
|
On Router 5 we have the neighbor
|
|
0:12:18
|
that is Router 1
|
|
0:12:23
|
we're using the IPv6 address of Router 1
|
|
0:12:27
|
then we're saying in addition to the IPv4 unicast address family
|
|
0:12:31
|
which is on by default, I also want to run IPv6 unicast.
|
|
0:12:38
|
So now if we look at the show ip bgp neighbors
|
|
0:12:49
|
it says we have a new address family capability
|
|
0:12:52
|
which includes IPv4 unicast and now IPv6 unicast as well.
|
|
0:13:00
|
So from this point on any advertisements or attribute
|
|
0:13:03
|
modification for IPv6 specific routes, that would then go
|
|
0:13:08
|
under the IPv6 unicast address family.
|
|
0:13:12
|
So if Router 5 wanted to go to the BGP process
|
|
0:13:20
|
and under address family IPv6 unicast
|
|
0:13:25
|
specify that we're going to do a network advertisement
|
|
0:13:29
|
if we show ipv6 route connected
|
|
0:13:34
|
we'll say advertise Fast Ethernet 0/1
|
|
0:13:38
|
so that exact prefix is going to get advertised into
|
|
0:13:41
|
IPv6 BGP
|
|
0:13:49
|
then on Router 1 when we look at the show ipv6 route bgp
|
|
0:13:57
|
or show ipv6 bgp
|
|
0:14:02
|
and you'll see in some versions they take the syntax
|
|
0:14:05
|
like this, some versions you'll have to say
|
|
0:14:09
|
show bgp, then followed by the address family and the
|
|
0:14:12
|
sub address family identifier similar to what we
|
|
0:14:14
|
were doing before with MPLS.
|
|
0:14:17
|
So if we say here show bgp ipv6 unicast
|
|
0:14:21
|
this is the equivalent of the show ip bgp
|
|
0:14:25
|
If I said show bgp ipv6 unicast summary
|
|
0:14:31
|
it shows we have the peering that's going over to Router 5
|
|
0:14:38
|
If we show bgp ipv6 unicast and then this particular prefix
|
|
0:14:46
|
we see we have the next hop value
|
|
0:14:49
|
it says it's being learned from -- or actually it's
|
|
0:14:52
|
via this link local address
|
|
0:14:56
|
it's being learned from this particular neighbor
|
|
0:14:58
|
they have the router ID 150.28.5.5
|
|
0:15:01
|
Its origin was IGP, so it means it was coming from the
|
|
0:15:05
|
network statement.
|
|
0:15:06
|
Met is 0, local preference is 100, it's an external route
|
|
0:15:10
|
and this is the best path.
|
|
0:15:17
|
So from this point on the rest of the rules of BGP are
|
|
0:15:19
|
going to be the same.
|
|
0:15:21
|
The key is that you can do the peering independent from
|
|
0:15:25
|
the address family.
|
|
0:15:27
|
So now on Router 1, we're doing the peering
|
|
0:15:31
|
via IPv6
|
|
0:15:34
|
and we're also doing advertisements of IPv6 networks.
|
|
0:15:45
|
Now between Router 1 and Router 6
|
|
0:15:48
|
we're going to do an IPv4 BGP peering
|
|
0:15:53
|
but then use this to advertise the IPv6 address family.
|
|
0:15:59
|
So it's the opposite of what I did between Router 1
|
|
0:16:01
|
and Router 5
|
|
0:16:05
|
so on Router 1 let's go to bgp 1
|
|
0:16:08
|
we'll specify there's a neighbor 155.28.146.6
|
|
0:16:12
|
who is in as 6
|
|
0:16:19
|
Router 6 is going to say the same thing, so there's a
|
|
0:16:22
|
neighbor that is Router 1
|
|
0:16:24
|
who is in as 1
|
|
0:16:28
|
but now under the address family ipv6 unicast
|
|
0:16:32
|
I'm going to activate this neighbor.
|
|
0:16:39
|
Router 1 is going to do the same thing.
|
|
0:16:42
|
So address family IPv6 unicast
|
|
0:16:54
|
and if we did not want to run the IPv4 unicast address family
|
|
0:16:58
|
between the neighbors, we could either globally under the
|
|
0:17:02
|
process say no bgp default ipv4 unicast
|
|
0:17:12
|
where this basically says do not automatically negotiate
|
|
0:17:16
|
that particular address family identifier
|
|
0:17:20
|
or we could specifically go under the address family IPv4
|
|
0:17:23
|
unicast and say for this neighbor I do not want to activate them.
|
|
0:17:49
|
So Router 6 is going to say the same thing
|
|
0:17:51
|
no neighbor Router 1's address activate.
|
|
0:17:55
|
Once the peering comes back up if we look at the show bgp neighbors
|
|
0:18:01
|
or show ip bgp neighbors
|
|
0:18:07
|
we should see that the control plane transport
|
|
0:18:11
|
is TCP running over IP version 4
|
|
0:18:17
|
but the information that the neighbors are going to advertise
|
|
0:18:21
|
is IPv6
|
|
0:18:25
|
so what I need to say here then is show bgp ipv6 unicast neighbors
|
|
0:18:35
|
which again is kind of odd because it's an IPv4 address
|
|
0:18:39
|
that is the IPv6 unicast neighbor where we have the
|
|
0:18:43
|
IPv6 unicast address family advertised and received
|
|
0:18:50
|
also this version supports the new autonomous system numbers
|
|
0:18:54
|
which are the 4-byte AS values.
|
|
0:18:56
|
If we now look at the show bgp ipv6 unicast
|
|
0:19:02
|
we see that now we're learning the route towards
|
|
0:19:04
|
Router 5's BGP route, but the next hop value points to an
|
|
0:19:10
|
IPv4 address.
|
|
0:19:18
|
So just like I had to do previously with the IPv4
|
|
0:19:23
|
address family over the IPv6 transport
|
|
0:19:27
|
on Router 6 as I receive the update in from Router 1
|
|
0:19:31
|
I'm going to have to change the next hop value
|
|
0:19:34
|
so it points to my legitimate IPv6 neighbor
|
|
0:19:39
|
so specifically this neighbor's address if we look at the
|
|
0:19:42
|
show ipv6 neighbor
|
|
0:19:44
|
I want it to point at either this address of Router 1
|
|
0:19:48
|
or the link local address of Router 1
|
|
0:19:51
|
either of them are going to be fine because it's essentially going to
|
|
0:19:53
|
point towards the same neighbor.
|
|
0:19:58
|
Just the problem is now that when we look at the detail
|
|
0:20:00
|
for this route, we cannot use it for best path selection
|
|
0:20:06
|
because it says this next hop is inaccessible.
|
|
0:20:10
|
Basically this is just an invalid value that's there.
|
|
0:20:14
|
So this has to point to an IPv6 address, not to an
|
|
0:20:17
|
IPv4 address.
|
|
0:20:21
|
There is one exception to this which is a feature
|
|
0:20:24
|
that is known as 6PE
|
|
0:20:35
|
and 6PE is basically a special encoding for multiprotocol BGP
|
|
0:20:41
|
updates that can be used to advertise IPv6
|
|
0:20:46
|
routes over the VPNv4 address family in MPLS.
|
|
0:20:53
|
So there's really two points that are kind of interesting
|
|
0:20:55
|
about how this works
|
|
0:20:58
|
that the next hop value
|
|
0:21:03
|
it says that the multiprotocol BGP creates a BGP update
|
|
0:21:09
|
including the reach network layer reachability information
|
|
0:21:12
|
that is AFI 2 SAFI 4
|
|
0:21:18
|
which is an IPv6 labeled route
|
|
0:21:23
|
which it gives them not only the prefix, but it gives them an
|
|
0:21:28
|
MPLS label for it and points the next hop to an IPv4
|
|
0:21:33
|
neighbor, so it's kind of a hack on the process and
|
|
0:21:38
|
it's kind of interesting to read through this.
|
|
0:21:41
|
Basically this is the transition mechanism for service providers
|
|
0:21:44
|
that are running IP version 4 based MPLS
|
|
0:21:48
|
for them to support IPv6 transport over this particular network
|
|
0:21:54
|
because the idea is that in the service provider core
|
|
0:21:57
|
we don't want to have to enable -- we don't want to have to
|
|
0:22:00
|
enable IPv6
|
|
0:22:02
|
so the core is already running MPLS and IPv4 transport.
|
|
0:22:07
|
So between these two PEs that are running IPv6
|
|
0:22:12
|
they're exchanging the IPv6 routes
|
|
0:22:15
|
but the next hop value points to an IPv4 destination
|
|
0:22:21
|
that we can use an MPLS transport label
|
|
0:22:24
|
in order to reach.
|
|
0:22:26
|
So we're basically tunneling IPv6 over MPLS by using
|
|
0:22:30
|
an IPv4 next hop.
|
|
0:22:34
|
So this feature is definitely not going to be within the scope of
|
|
0:22:37
|
the routing and switching exam, but it is kind of interesting to know
|
|
0:22:40
|
how this works because this is one of the transition mechanisms
|
|
0:22:43
|
that's moving as closer to having ubiquitous IPv6 support.
|
|
0:22:52
|
So again, the problem I'm running into now here with Router 6
|
|
0:22:55
|
is that it's receiving the update in, but it's coming in with an
|
|
0:22:59
|
invalid next hop value, so what I need to do now is
|
|
0:23:02
|
basically change this so it points at Router 1
|
|
0:23:06
|
so I'll have a route map that says from Router 1
|
|
0:23:12
|
that sets the IPv6 next hop value to Router 1's address
|
|
0:23:21
|
then under BGP 6
|
|
0:23:24
|
address family IPv6 unicast
|
|
0:23:28
|
the neighbor's address again is the IPv4 address of Router 1
|
|
0:23:38
|
and I'm applying the route map from Router 1
|
|
0:23:44
|
inbound.
|
|
0:23:50
|
Now if I ask for route refresh if I say clear bgp
|
|
0:23:54
|
ipv6 unicast inbound
|
|
0:24:00
|
for * in
|
|
0:24:03
|
then show bgp ipv6 unicast for this particular prefix
|
|
0:24:12
|
Now we see the next hop value has been changed to
|
|
0:24:15
|
the IPv6 address of Router 1
|
|
0:24:17
|
which means ultimately I can perform route recursion on this
|
|
0:24:21
|
and then install it into the routing table.
|
|
0:24:24
|
So if I show ipv6 route bgp
|
|
0:24:29
|
now the route is installed and I should be able to
|
|
0:24:35
|
send traffic to this destination.
|
|
0:24:47
|
Now whether I can actually reach this or not is going to depend
|
|
0:24:50
|
if Router 5 has a route back because right now
|
|
0:24:53
|
Router 6 is not advertising anything so if I were to go to
|
|
0:24:56
|
Router 5 let's look at the debug ipv6 packets
|
|
0:25:01
|
I want to know at least is Router 5 receiving the packets
|
|
0:25:06
|
in from 6
|
|
0:25:12
|
which it is.
|
|
0:25:14
|
So the packets got from 6 to 5, but then 5 is doing a
|
|
0:25:19
|
routing lookup and it doesn't have a route back to the source.
|
|
0:25:22
|
So that's fine, that's not really Router 6's problem
|
|
0:25:25
|
that's Router 5's problem because it doesn't have that
|
|
0:25:27
|
particular route back.
|
|
0:25:29
|
But we can tell at least one way the traffic is getting there.
|
|
0:25:38
|
So again, let's look at our final configurations for this on Router 1
|
|
0:25:42
|
show run section router bgp
|
|
0:25:47
|
We have an IPv6 neighbor that we are running the IPv6
|
|
0:25:52
|
address family with,
|
|
0:25:54
|
but then we also have an IPv4 neighbor that we're running
|
|
0:25:57
|
the IPv6 address family with.
|
|
0:26:02
|
So the key point being here that the transport of BGP
|
|
0:26:05
|
is independent of the address families that it is advertising.
|