we can extend customer vrf s-- across several core routers using multi
protocol BGP I've mentioned a few times throughout the series that VR F's are
local to each router one router doesn't know anything about VR F's on another
router but this can present a problem picture a service provider network the
core of the network is likely made up of many routers and they have many
customers connecting in it's not scalable to configure every vrf on every
router the effort required for that is immense instead we can extend BGP in the
core to share customer routes independent of V refs while still
keeping customers separate from each other routers on the edge still run VRS
of course as usual it's easier to see it in action so let's take a look at the
lab we're going to build our core network by adding another core router
connected to this is another customer a and customer beer outer loop backs are
again used to simulate customer networks the ultimate goal will be to forward a
network traffic between customer routers across our core this means sharing route
information while keeping customers separate from each other the lab files
are on the website of course so you can follow along or practice on your own I'd
just like to mention that what you see here is a lab and does not follow all
the best practices that you would hope to see in the real world we've seen some
of this before so I'm going to move through this fairly quickly here we're
creating the vrf and enabling ipv4 we had the transit link to the vrf and add
the IP addresses back in
now we're starting the OSPF process and advertising the transit link
now over to the customer router we start OSPF advertise the networks and form a
neighbor relationship
same as in the last video we change the network type on the loop backs now we
can move over to customer be this part will be quite quick too
we create the vrf we add the link to the vrf
and we advertise the transit link into EIGRP
on the customer router we also configure er GRP
you
when the transit link is advertised the neighbor comes right up
and finally we quickly double check that we have connectivity
now it's time to get bgp running between the core routers there's a single link
between the core routers this is a routed link with the network existing in
the global routing table we're starting on the core 2 router there's a few
simple things that we need to get ready first this includes a loopback interface
this is used as the bgp router ID and the IP used for ibgp communication we're
also adding a static route to get to the loopback of the other router
and now we can configure an ibgp neighbor
as this is ibgp I'm using a loopback interface as the source of my BGP
traffic this uses a global routing table so there's no need for any vrf commands
core 1 already has some bgp config like a loopback interface we do need a route
to get to core two's loopback though it's the same b2b config here nothing
special at all except that I regularly have problems felling neighbor does
anyone else outside the US have their problem is just me anyway moving on
we'll stop manually advertising the customer networks that we set up in the
last video we're moving to an automated setup here
and we'd better just check that the neighbors are fine and it looks like the
neighbors aren't up yet okay just give me a moment I'll figure that one out
right I've got it now due to my typos earlier I didn't actually enter the
neighbor command correctly
there we go it's up now this has been pretty basic so far nothing you haven't
seen before I'm sure but now it's time to make things a little more interesting
when bgp learns a prefix what does it do it stores in a database right but this
presents a little bit of a problem we have customers and we want to keep
them separate there's even some overlapping IP space in our case if all
the prefixes are in one single BGP database won't they all get mixed up
won't the overlapping IP address ranges conflict somehow well it's good news on
this front with a bit of assistance from us BGP is smart enough to handle this
situation we can give each of the RF an identifier called a route distinguisher
when a route is added into BGP the route distinguished R is added with it this
keeps each prefix unique in the database the route distinguisher itself is a
64-bit value it is usually broken up into two 32-bit values separated by a
colon like this it's a good idea to use your local autonomous system number as
the first part that's the 65,000 in this example the second part is usually a
number that you choose to represent your vrf you have to choose a different
number for each of the RF to give the unique route distinguishers are unique
to every device that means we don't send them to any other router anyway to
configure an RD well that's really simple we just enter the v RF and we set
the route distinguisher with the Rd command
you might remember doing this on the core line router for customer B in the
last video we're using the value of 10 for customer a and 20 for customer be
any numbers will do really as long as they're unique it's really easy to check
what the ID is set to just use show IP v RF
we can also see this on the prefixes in the BGP database notice that now they're
called VPN v4 prefixes we've added a little bit more information to the
prefix now that's the raddest English R so it's not simply an IP route at least
not from BGP sper spective core 2 doesn't have any prefixes yet after all
we haven't given anything to learn we'll take care of that in just a moment
if we want we can grab a bit more information by adding the detail keyword
our customers are running their own iGPS and in the core we're running BGP to get
them to work together we need to enable redistribution we already redistributed
BGP routes into customer B on this router during the last lab but we still
need to redistribute both into BGP
as the same deal on the core 2 router we need to redistribute bgp routes into the
customers eye GPS as well as redistributing the eye GPS into BGP
you
now we can double-check that the customer routes are in the BGP database
looks good here let's check on the other core router and it's good to but notice
that we only see routes from the customer routers that are directly
attached we don't see all the customer routes yet this is what we're going to
configure next so far our core routers are joined by a single link this link is
in the global routing table so how can we get routes from one vrf across this
link and back into the correct vrf on the other side reroutes can be passed
over the link in the mill but they need to be kept unique a real distinct we
sure cannot help here as they're local to each router instead we can put a tag
on each route to identify them as belonging to a particular customer this
part of the process is called exporting this tag is called a route target and it
looks very much like a route distinguisher in fact we often use the
same value for both remember though that while they look the same a route target
and a route distinguisher are different things a route distinguisher keeps the
prefix unique in the local BGP database while our out target is used to keep a
route unique when passing from one router to another when a router receives
the prefix it looks at the tag and puts it into the correct vrf this part of the
process is called importing let's now take a look at how to make this happen
we can figure out targets within the customers vrf there are two parts to
this the part we're doing here is exporting this takes all the routes in
the vrf and adds the customers tag to it we've used the same value as the router
sting wishers simply for convenience they are completely separate things and
we could use different numbers if we want to but exporting is only half the
process when we receive routes from another rather we need to import them
into the correct vrf here we tell the router to import any incoming
it's tagged with 65,000 ten into customer bees vrf hold on a sec that's
my mistake there that's supposed to be sixty five thousand twenty into customer
B will put routes tagged with sixty five thousand ten into a customer a
and of course we do the same thing on the other core router a little
configuration trick to make things a bit quicker is to use the both keyword this
both imports and exports in one command
we're almost done we just need to make some small changes to the neighbor
relationships between the core routers we need to go into the VPN v4 address
family ipv4 routes with our target attached I'll call the VP and v4 prefix
we activate the neighbor on this address family to get the routers to share these
prefixes as soon as we do this we see a change in the peering new capabilities
have been added route targets are sent as a BGP extended community that means
we also need to enable communities here because this is ibgp will also enable
next top self we'll do the same thing on in call one of course
and we still see their neighbors adding new capabilities as soon as they're
activated
if we verify the routes in both brf's we can see that all customer routes have
now been learned the same is true on the second core
router
you
and if we look at the customer routers we also see that the routes have been
line there as well
they show up as into area OSPF routes or externally IG RP routes
time to see it in action let's ping from a customer router on one side of the
network to the other side of the network and that's working first go it never
works first go something's not right
yep yep I'm peeing local networks of course that'll work
okay if we ping the right networks they'll fail that's what we're expecting
to see but all the routes that are in place we've just seen that so what's
actually going on here remember that all we've done is configure this environment
to learn routes but there's more to networking than just learning routes
consider this transit link did we put these interfaces into a ver F now we
didn't they're in the global routing table so traffic in a customer network
can't reach the next hop this is traffic segregation in action so what are we
supposed to do an interface can't be in more than one vrf so that's not an
option we could run a separate link for each customer but that has scalability
issues what if we had hundreds of customers we need a technology that
encapsulates customer traffic and sends it over this link something like a VPN
the most common technology in this case is MPLS MPLS is a label switching
technology it takes a packet places a label in the front that traffic is then
forwarded over the link using the label rather than just the IP address no IP
addresses means that the global routing table is no longer a problem when the
packet reaches the other side the label is removed and the original packet is
forwarded as normal for our simple lab configuration is easy we just go into
the interfaces for the transit link and enter the MPLS IP command
when we do this a protocol called ldp forms a relationship between the two
routers LDP is the protocol responsible for assigning labels and just like that
we can now ping from one side of the network to the other
that's a rather simplistic view on MPLS there's a whole lot more than what we've
talked about here if you're interested in knowing more let me know in the
comments there F's are used to keep traffic completely separate but what if
we want to allow some of the traffic to mix this is called Route leaking which
is the subject of our final video