Typically, an organization can obtain an Internet-legal AS number. Like IP addresses, you also have private AS numbers.
BGP redefines what we consider "neighbors". You can actually have BGP neighbors that are NOT directly connected. The routing to the other neighbors can then be done with IGPs like OSPF and RIP.
We'll do our first BGP configuration using this topology:
IBGP is commonly run on routers connected to multiple ISPs in the same AS. This is used to provide redundancy. Organizations with such redundant connections typically become a transit AS. Transit AS's become a "node" in the public routing network where public traffic goes through.
Beware, though, being a transit AS you may create Networking Blackholes if you run IBGP with non-directly-connected neighbors.
Suppose that the 12.23.34.0/24 network wants to communicate with the 23.34.45.0/24 network, and your AS is the transit AS that has the best metric, the packet would go through you.
However, remember that only the IBGP routers know about 12.23.34.0/24 and 23.34.45.0/24, so as it goes into your IGP domain, the router on the inside would not know where to route it. Therefore, the packet would be dropped! You have thus created a Networking Blackhole in the Internet where every packet in transit would be dropped!
There are three ways to solve this. The first is to simply redistribute BGP into your IGP. However, this is not recommended as IGP is not made to handle such traffic.
The second way is to have your IGP router also run IBGP. That way, they would all have the routes and would go through.
The final and recommended way is to actually have a direct link between both of your IBGP routers.
Now we'll begin some BGP basics. This will accomplish both IBGP and EBGP relationships:
For each link, the router with the lower router number will get the lower host address. All links are FastEthernet.
We'll begin configuration on the ISP router first. We'll put the ISP router in AS 2000 first:
router bgp 2000The ISP router is 10.0.0.18/30, so R3 would be 10.0.0.17/30. We'll add R3 to the ISP's neighbors:
neighbor 10.0.0.17 remote-as 1000There are many things you can do with a neighbor, but the first command you need to enter is the remote-as command. Other commands will not be accepted until this command is present. R5 is now attempting to connect to R3.
To see the configured neighbors, use:
show ip bgp sumIf you haven't configured the other side yet (hopefully, since you're following this), you would have the state of the neighbor written as "Active". Remember, "Active" is something bad. It means that the router is actively trying to establish the relationship.
We'll now hop over to R3 and put it in AS 1000:
router bgp 1000The same way, we'll add R5 as a neighbor:
neighbor 10.0.0.18 remote-as 2000You may have to wait some time for the neighborship to come up. If you check the neighbors, you'll see that the neighbor is "Idle". "Idle" means that it knows that the router is there, but it hasn't attempted to establish a connection yet.
EBGP should come up by now. We'll now configure IBGP. There's no difference in configuration, except that the remote-as of the neighbor is the same as its own. Now, assuming that OSPF is up and running, we'll add R1 to the neighbor table.
Now, for R1, there are two addresses we can use: 10.0.0.1 and 10.0.0.13. However, if we choose one and it goes down, the neighbor relationship would go down. We should use neither one of this, and instead peer with a Loopback address. The Loopback would be advertised into OSPF!
On R1, we have a Loopback address 10.0.1.1/32 advertised into OSPF. The other routers all have 10.0.1.x/32 Loopbacks advertised. We'll now peer with the Loopback from R3:
neighbor 10.0.1.1 remote-as 1000At this point, the neighborship won't come up even if both sides are configured to use each other's Loopbacks. This is because the connection is established from a FastEthernet interface. The other side would not recognize it as a neighbor and so the relationship will not come up. The way to fix this is to change the update source:
neighbor 10.0.1.1 update-source lo0Do this for R1 as well:
router bgp 1000
neighbor 10.0.1.3 remote-as 1000
neighbor 10.0.1.3 update-source lo0Now they'll try to use their Loopbacks to establish the relationship with each other's Loopbacks.
Now, what if we have redundant ways to get to an ISP router? For example, what is R3 has two links to get to R4? The way to do this is to create two static route to the opposite router's Loopback interface (assuming you have another link at 10.0.0.20/30):
ip route 10.0.1.5 255.255.255.255 10.0.0.18
ip route 10.0.1.5 255.255.255.255 10.0.0.22The ISP would also have to create two static routes back. After this is done, and even after adding each other's Loopback interfaces, and changing the update-source, the neighbor relationship would still not come up! This is because by default EBGP neighbors MUST be directly connected!
To change this, we'll need to make use of multihop. To do this, we'll need to type:
neighbor 10.0.1.5 ebgp-multihop 2This is all the commands we'll need on R3 to peer with R5's Loopback:
ip route 10.0.1.5 255.255.255.255 10.0.0.18
ip route 10.0.1.5 255.255.255.255 10.0.0.22
router bgp 1000
neighbor 10.0.1.5 remote-as 2000
neighbor 10.0.1.5 update-source lo0
neighbor 10.0.1.5 ebgp-multihop 2You would have to mirror the configuration for R5:
ip route 10.0.1.4 255.255.255.255 10.0.0.17
ip route 10.0.1.4 255.255.255.255 10.0.0.21
router bgp 2000
neighbor 10.0.1.4 remote-as 1000
neighbor 10.0.1.4 update-source lo0
neighbor 10.0.1.4 ebgp-multihop 2This article focuses only on neighbor relationships. We'll talk about advertisements in future articles.
This sentence is here to test if Mr Soma would one day end up here through Google. Here's some keywords to help him out: L Somasundaram, IFC Alumni Advisor, 67805602, somasun@tp.edu.sg, Network Security, GreatSoma.
Network Security is my favorite subject! (<- I think Mr Soma came here to see this.)
On a side note, what does L stand for? I really couldn't find it in Google.
No comments :
Post a Comment