Now it's time to jump in the virtual lab
and build our first neighbor relationship.
This is going to be a pretty simple configuration,
but what it's going to reveal--
very quickly-- is all of the subtle nuances
that there are to BGP.
And that's going to set up a lot more topics
that we're going to talk about throughout the rest
of this skill.
Now, let me jump on a whiteboard and demonstrate to you
what the scenario is that we're configuring.
This is the virtual lab topology that we're
going to be working with throughout these BGP series,
and what we're focusing on on this Nugget
is this link right here-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is this link right here--
a link that exists from AS 100 to AS 200.
In fact, let's zoom in a little bit
so we get a better view of it.
Yeah, there we go.
That's a lot better.
OK, so what we have here is a scenario where we have
a carrier here-- represented with AS 100--
and a different carrier here--
represented with AS 200.
It's not a stretch to think that there's a scenario where there
may be a server down here with a public IP address that
needs to be advertised out to the internet.
So by establishing a peering relationship between these, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So by establishing a peering relationship between these,
we can now advertise the network for this server
to a different carrier, who can then
forward that advertisement out to a different carrier,
or maybe off this link here.
The flip side of that is is maybe from AS 200 there is
a whole network of servers here--
maybe it's a data center--
and from AS 200, they want to advertise networks down to us.
Now, like we said earlier, there's
no dynamic discovery that happens in BGP.
We have to specify the IP address of our peering router.
We also have to specify the remote autonomous WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We also have to specify the remote autonomous
system-- the autonomous system of the neighbor
that we're peering with.
Ultimately, the command looks something like this.
We're going to specify the neighbor, the neighbor's IP
address, then the remote AS and their remote autonomous system.
This command must be run before you
can configure other aspects of your relationship.
It has to specify what the IP address is
of our peer and the autonomous system.
But once this has been configured on both sides, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But once this has been configured on both sides,
they will begin immediately trying to form a neighbor
relationship.
And that's what we're going to set up in this Nugget.
So what we're going to work with in this virtual lab
is we're going to be working with R2 and R4.
Let's jump in the virtual lab and take a look
at what we've got.
So I fired up the virtual lab, and we
are working, again, with the link between R2 and R4.
On both sides, this is using fa--
fast ethernet-- port 4/0.
So I'll write fa 4/0 on both sides. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I'll write fa 4/0 on both sides.
And-- just as a reminder--
R2 is going to be representing Autonomous System 100,
and R4 is going to be representing Autonomous System
200.
Why don't we get started getting a lay of the land,
and then fire up our BGP instance
and build a neighbor relationship?
For the time I'm going to leave this writing on the screen--
just as a reminder.
We'll run show ip interface brief, and we can see,
on fa 4/0, we're working with the 100.100.24--
that's for router 2 and router 4-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's for router 2 and router 4--
.2 subnet.
I'm not highlighting the mask right now,
because that's a very important factor when it comes to BGP.
Now, on the other side of things,
we can jump over to R4 by just clicking on R4 tab,
give it a show ip interface brief, and on fa 4/0,
we see we've got 100.100.24--
again, for routers 2 and 4--
and .4 to specify that we're using router 4.
So let's start with router 2.
To configure BGP, we're going to go and do configure terminal.
We're going to type router BGP, and then it's not a process ID, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're going to type router BGP, and then it's not a process ID,
it's not an area number, but it is our autonomous system.
This is Autonomous System 100 in this case.
Before I do anything else, I want
to point out that once you've declared
this is my autonomous system--
Autonomous System 100--
I can't specify another instance of BGP
for the different autonomous system.
If I tried BGP 101 here, it says BGP is already running,
and you're in AS 100.
A router can only represent one autonomous system.
So now let's jump into BGP 100. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now let's jump into BGP 100.
And remember, I said before you can do anything
else as far as neighbor relationships go,
we have to declare who our neighbor is
and what remote autonomous system they're in.
While there is a network statement in BGP,
it's not for discovery.
We're going to explore the network statement
in just a minute.
Let's get our neighbor relationship stood up first.
I'll use neighbor, then the remote IP
address of our neighbor that we're connecting to--
in this case 100.100.24.4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in this case 100.100.24.4.
And then remember what came after that?
The remote AS.
If I hit question mark, you can see
there's actually a lot of things that we
can set that deal with our relationship
with this neighbor.
But the one that we have to specify is remote AS.
So let me tell it that the remote AS is going
to be Autonomous System 200.
So it now has the details of our neighbor relationship,
and R2 is currently trying to form a neighbor relationship WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and R2 is currently trying to form a neighbor relationship
with them.
It's using TCP.
It's sending a packet to destination 179.
Nothing's coming up yet, because R4 doesn't know anything
about BGP.
Let's go ahead and configure this.
We'll say router BGP.
In this case, R4 was representing Autonomous System
200.
And we know the neighbor is going to be 100.100.24.2,
and the remote autonomous system is 100.
Let's press Enter, and look at that-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's press Enter, and look at that--
after a few seconds, we see, right there,
the syslog message neighbor 100.100.24.2 came up.
That seems really simple, but actually, under the hood,
a lot happened.
And this, my friends, is going to require a whiteboard,
because it's important.
Let's draw this up like this.
We've got R2, R4, the link between them,
and we know that the network that we were working with here
was 100.100.24.0. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
was 100.100.24.0.
When we told R2 that its neighbor was 100.100.24.4,
R2 knew that it was going to have to send a packet destined
to this IP address and destined to port 179.
In order to make it to this IP address,
it looked at its routing table--
or the routing information base.
And in the routing table, it saw that it had a locally connected WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And in the routing table, it saw that it had a locally connected
interface to that network.
So while the destination portion of the packet was destined
to 100.100.24.4, the source portion of the packet was
sourced based on the IP address that was closest,
or that was in the routing table--
in this case, 100.100.24.2.
When R4 received this packet, it looked at the source IP
address.
Where was the source from? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Where was the source from?
And it checked its BGP table to see
if it had any neighbors configured
with that specific address.
Because we had typed the exact statement 100.100.24.2,
it saw that this packet that came in from 100.100.24.2
matched a neighbor statement.
It then validated that the autonomous system that was sent
in that TCP packet matched the remote AS statement-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in that TCP packet matched the remote AS statement--
which it did--
and it knew that this was a valid neighbor
that it could form a neighbor relationship with.
The flip side happened over here on R2.
When R4 sent a packet destined to 100.100.24.2,
it checked its routing table, saw that it had a locally
connected interface, and sourced its traffic to R2 from that
locally connected interface-- which was 100.100.24.4.
Because R2 was configured to have a neighbor with that IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Because R2 was configured to have a neighbor with that IP
address, the neighbor relationship
was able to come up.
So now let's jump back into the virtual lab
and verify our neighbor relationship just a little bit,
and set up some of the bigger nuances that there are to BGP.
I'm going to run the command, on R2, from privilege mode, show
ip bgp neighbors.
Well, the first thing we can see-- we see our BGP neighbor,
100.100.24.4, the remote AS, external link--
this is a big deal. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this is a big deal.
There is a difference between external BGP and internal BGP,
and that is what the next Nugget is going to be all about.
We should also take a look at the router ID.
This is the remote router ID.
By default, BGP picks the highest-addressed loopback
address.
If there are no loopback addresses,
it picks the highest physical address.
Timers are also a pretty big deal in BGP.
The default hold timer on Cisco routers is 180 seconds. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The default hold timer on Cisco routers is 180 seconds.
This means that our relationship-- our neighbor
relationship-- will be valid for 180 seconds,
and if we don't receive a keep alive in 180 seconds,
we send out TCP messages that tear down the relationship.
We say that the relationship is no longer valid.
Now, keep alives are sent every 60 seconds--
one third of the whole time.
You may be thinking to yourself, coming from the IGP world,
these are pretty long times.
And that's, quite frankly, because BGP is so massive.
There's so much that happens all the time with BGP-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
There's so much that happens all the time with BGP--
because there's hundreds of thousands
of routes out there on the internet-- that
having any shorter times could cause floods of traffic.
Our neighbor and us exchange capabilities.
What are the things that we can send and receive?
BGP has evolved a lot over time.
In fact, I like to point out this four-octet ASN right here.
This is actually talking about the 32-bit autonomous system
number.
You see, when BGP first rolled around, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
You see, when BGP first rolled around,
we had 16-bit autonomous system numbers,
meaning that our autonomous systems
could go from 1 to 65,535.
Clearly there's a lot more service providers and a lot
more autonomous systems out there now than there are
65,535, so they as expanded it, after the fact,
to a 32-bit autonomous system number--
also known as a 4-byte AS, and now autonomous systems go up
to 4 million--
I'm not going to lie. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm not going to lie.
I had to Google it.
It's 4,294,967,295.
Just like there's public IPs and private IPs,
there are also public autonomous systems
and private autonomous systems.
We're going to talk about that in a later Nugget, too.
We see that we are using the IPv4 address family again.
Again, we're going to tackle that later
in this set of skills.
We can also see some interesting statistics, like our opens.
That's what formed our TCP connections.
Notifications typically happen when bad stuff happens. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Notifications typically happen when bad stuff happens.
Updates-- just like you would think,
we're updating capabilities, prefixes and networks,
and we also see how many keep alives
have happened with our neighbor.
And by default, you would think this is a healthy amount
of output, right?
Let me clear the screen.
You would think, yeah, this is some good output.
There can't be a whole lot more to this show ip bgp neighbor
command, could there?
Well, let's hit Spacebar.
Now we get into the address family specifics,
like what's happened for just IPv4 Unicast prefixes.
Scroll down some more, we can see some filters that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Scroll down some more, we can see some filters that
have happened in this area.
Keep on scrolling-- connection statistics.
Keep on scrolling some more, and then we finally get
to the-- yeah, this is a gigantic output
that comes back when we do show ip bgp neighbors,
and that's because you need to know this much info if you're
a service provider trying to build connections
to other service providers.
So cool, we've got this neighbor relationship formed,
but it's not really doing much, is it?
Well, I mean, there's a neighbor relationship,
but we're not sharing any routes with each other.
Why don't we fix that? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Why don't we fix that?
Let's just have a little fun here.
I'll do a show ip interface brief,
and we see we've got Loopback1 with an address of 2.2.2.2.
And you may have recalled, earlier,
that I said that mask was going to play a factor in this.
I think now is the time to demonstrate that.
So let's share a route to 2.2.2.2 to our partner
through BGP.
I'll go back into my BGP instance.
And to share a specific route that we know about,
we can specify the network command.
It says, what's the network number?
What's the network address? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
What's the network address?
So in this case, I'm going to share 2.2.2.2.
We'll press question mark one more time.
Now check this out.
The thing that we're focused on here
is we have to specify the exact subnet mask of the network
that we want to advertise.
There's no getting around it and doing something like 0.0.0.0,
because if I press Enter, look what happens.
It says incorrect network or mask, prefix length configured.
When we advertise a route in BGP,
it checks the routing table to make sure, first of all, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it checks the routing table to make sure, first of all,
can we advertise this route?
And it has to specify the exact mask.
So in this case, there is a 32-bit mask on this address,
so I'll have to say network 2.2.2.2 mask 255.255.255.255.
Let's also advertise, just for fun,
the IP address here of 172.16.12.2.
We don't advertise a specific address.
We actually advertise the subnet here.
So if I give this a do show interfaces gig 0/0, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if I give this a do show interfaces gig 0/0,
I can see my subnet is 172.16.12--
it's going to be .0/24.
So hopping back into my BGP instance,
I'll also advertise the 172.16.12.0 subnet,
and we'll have to specify the exact subnet mask.
There is a way that we can summarize these 172.16
addresses, and that's something that we'll cover
when we get to route filtering.
For now, I'll advertise those two networks, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
For now, I'll advertise those two networks,
and we'll jump over to R4 to make sure that it's
received those networks.
Back in privilege mode, I'll run the command
show ip bgp summary.
I think this one's pretty important, because we
can see who our neighbor is, and right here at the end,
how many prefixes have we received from them?
We also see some pretty interesting things,
like what's their remote AS?
How many messages have we sent and received?
But right there, I see that I've received two networks from
my partner over here at 100.100.24.2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
my partner over here at 100.100.24.2.
So if I give it a show ip bgp--
just by itself-- now I see the two networks
that I've received.
I also see their next hop location.
And if I give it a show ip route to look at the routing table,
I see I've got a couple networks, here, learned
from BGP.
So this sets up a very basic scenario of BGP.
We formed a neighbor relationship.
We explored how that neighbor relationship really
came up by looking at the source address that
came in from a packet, versus what we had configured WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
came in from a packet, versus what we had configured
in our neighbor statement in the BGP router process.
Validating that once those two match-- the source open packet
and what we configured-- the TCP session
and the BGP session came alive.
From there we shared a network to our peer
by specifying the exact prefix length that we needed in order
to share that network.
But this did set up a pretty big topic,
which is what's the difference between external BGP
and internal BGP?
And that's what the next Nugget's all about.
In the meantime, that's been standing up a basic BGP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In the meantime, that's been standing up a basic BGP
session.
I hope this has been informative for you,
and I'd like to thank you for viewing.