 |
|
|
|
|
|
|
|
|
|
» Forum |
|
 |
 |
  |
||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
 |
 |
 |
 |
||||||||||||||||||||||||||||||||||||||||||||||||||
 |
Documentation |
 | |
» Products | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
 |
|
Configuring and Testing Border Gateway Protocol (BGP)
|
|
One-octet field error subcode provides additional error information. Each error code can have one or more subcodes. If the field contains zero then no subcode is defined.
For testing an operability of BGP, NetUP specialists have built a testing stand including four autonomous systems:
AS 65001 including the net 192.168.100.0/24
AS 65002 including networks 172.16.100.0/24; 172.16.102.0/24; 172.16.103.0/24
AS 65003 including the network 192.168.200.0/24
AS 65004 including the network 172.16.101.0/24
As routers 3 servers with Linux Gentoo OS were used and one Cisco 3640. The stand scheme is on the figure below:
Figure 5. Stand scheme for testing BGP operability.
For a simple configuration of the Cisco router for working with BGP the following commands are used:
router bgp 65003 neighbor 172.16.101.2 remote-as 65004 neighbor 172.16.102.1 remote-as 65002 network 192.168.200.0
The command router bgp [AS] gives the router number of its autonomous system and includes exchange of BGP routes between autonomous systems.
The command neighbor [ip-address] remote-as [AS] adds in the table of neighbor BGP routers a record with an IP address of the router and the number of the autonomous system it belongs to.
The command network [ip-address] informs the router that the current network should be announced as available via the current router.
On selecting the best way to the destination network, in BGP several criteria are used; each of them can be configured manually. Route selecting algorithm consists of the following steps:
For each record in the table of neighbor routers we check if the respective unit is accessible, and reject those which are inaccessible.
Select the way with the greatest weight.
If the weight is identical, select the route with the maximal value of the LOCAL_PREF parameter.
If LOCAL_PREF values are identical and the route is initialized by an external (non-local) router, select the shortest AS_PATH.
If lengths of AS_PATH are identical, select the least ORIGIN code.
If codes of the ORIGIN attribute are equal, select the route with the least attribute MED value.
If attributes MED are identical, then eBGP is more preferred than iBGP.
If the routes are identical, then we select the nearest IGP neighbor.
If the distances are identical, then select a router with the least ID.
The attribute 'Weight' is a metrics and it allows the system administrator setting manually a certain weight to all routes information about has been received from BGP partners. The more Weight is, the better is the route. This metrics is especially useful when a router is connected to several autonomous systems. Weight remains a local parameter for the router it is configured at. When information about routes comes from many sources, the attribute is configured by using the command:
neighbor <IP address> weight <weight>
Allowable weight value lies in the range 0 - 65535. Default value is 32768.
After configuring BGP, a set of commands can be used for checking the configuration and diagnosing the network. These commands can be also used for studying BGP routing process:
show ip bgp shows all information concerned with BGP configuration for a selected interface;
show ip bgp neighbors outputs information about all configured BGP neighbors, provides detailed statistics relevant to each neighbor router;
show ip bgp paths shows all routing information for a local router;
show ip bgp summary displays status of all BGP connections.
Example of using the command show ip bgp:
Router#show ip bgp
BGP table version is 67, local router ID is 172.16.101.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 172.16.100.0/24 172.16.102.1 0 0 65002 i
* 172.16.101.2 0 65004 65002 i
r 172.16.101.0/24 172.16.102.1 0 65002 65004 i
r> 172.16.101.2 0 0 65004 i
r> 172.16.102.0/24 172.16.102.1 0 0 65002 i
r 172.16.101.2 0 65004 65002 i
*> 172.16.103.0/24 172.16.102.1 0 0 65002 i
* 172.16.101.2 0 65004 65002 i
*> 192.168.100.0 172.16.102.1 0 65002 65001 i
* 172.16.101.2 0 65004 65002 65001 i
Quagga is the software package realizing TCP/IP -based routing protocols. Such protocols as RIPv1, RIPv2, RIPng, OSPFv2, OSPFv3, BGP-4 and BGP-4+ are supported. In addition to the standard IPv4, Quagga also supports routing protocols for IPv6.
Quagga allows realizing routing functions on a separate computer by exchanging routing information with neighbors and correcting the core routing table. You can dynamically change Quagga configuration and view current configuration information.
For installing Quagga use the following command:
emerge quagga
The package includes a set of daemons for working with various routing protocols (ripd, bgpd, ospfd, etc.), and also the daemon zebra that is used for creation of the routing table and redistribution of routes between various protocols. Quagga configuration files are accessible in the directory /etc/quagga.
Below are the configuration files for all three routers used in the testing stand.
An example of zebra.conf:
hostname amalfi password zebra enable password zebra log file /var/log/zebra.log interface eth0 interface eth1 ip forwarding line vty
An example of bgpd.conf:
hostname amalfi_bgpd password zebra router bgp 65001 bgp router-id 10.1.2.4 network 192.168.100.0/24 neighbor 10.1.2.8 remote-as 65002 log stdout
An example of zebra.conf:
hostname sat password zebra enable password zebra log file /var/log/zebra.log interface eth0 interface eth1 ip forwarding line vty
An example of bgpd.conf:
hostname sat_bgpd password zebra router bgp 65004 bgp router-id 172.16.103.2 network 172.16.101.0/24 neighbor 172.16.103.1 remote-as 65002 neighbor 172.16.101.1 remote-as 65003 log stdout
An example of zebra.conf:
hostname streamer password zebra enable password zebra log file /var/log/zebra.log interface eth0 interface eth1 ip forwarding line vty no exec-timeout
An example of bgpd.conf:
hostname streamer_bgpd password zebra router bgp 65002 bgp router-id 10.1.2.8 network 172.16.100.0/24 network 172.16.102.0/24 network 172.16.103.0/24 neighbor 10.1.2.4 remote-as 65001 neighbor 172.16.102.2 remote-as 65003 neighbor 172.16.103.2 remote-as 65004 log stdout
When the configuration is complete it's necessary to run the daemons by using the commands:
/etc/init.d/zebra start /etc/init.d/bgpd start
The daemons can be managed via the telnet protocol, similarly to managing the Cisco router. For that connect to the port 2601 (for zebra) or to the port 2605 (for bgpd) and enter the passwords specified in the configuration files. An example of running the command show ip route bgp on the router amalfi:
amalfi# show ip route bgp
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route
B>* 172.16.100.0/24 [20/0] via 10.1.2.8, eth0, 00:12:45
B>* 172.16.101.0/24 [20/0] via 10.1.2.8, eth0, 00:12:15
B>* 172.16.102.0/24 [20/0] via 10.1.2.8, eth0, 00:12:45
B>* 172.16.103.0/24 [20/0] via 10.1.2.8, eth0, 00:12:45
amalfi# exit
The example shows that the router has successfully received via BGP a list of accessible autonomous systems.
Thus, on the stand we've got two independent routes from AS 65003 to AS 65001:
AS 65004 -> AS 65002 -> AS 65001
AS 65002 -> AS 65001
The first route is accessible via the interface Ethernet0/0:
interface Ethernet0/0 ip address 172.16.101.1 255.255.255.0
The second route - via Ethernet0/1:
interface Ethernet0/1 ip address 172.16.102.2 255.255.255.0
Firstly both routes are operable, and according to the algorithm of route selecting (see above) it should be selected the second route (65002 -> 65001). Let's check this using the command traceroute on the Cisco router:
Router#traceroute 192.168.100.1 Type escape sequence to abort. Tracing the route to 192.168.100.1 1 172.16.102.1 12 msec 48 msec 0 msec 2 192.168.100.1 [AS 65001] 0 msec 0 msec 4 msec
Now let's disable the short route. For that disable the appropriate networking interface on the Cisco router:
interface Ethernet0/1 shutdown
After that all traffic to AS 65001 should go via the reserve channel. Let's check this by using the command traceroute:
Router#traceroute 192.168.100.1 Type escape sequence to abort. Tracing the route to 192.168.100.1 1 172.16.101.2 0 msec 0 msec 0 msec 2 172.16.103.1 [AS 65002] 0 msec 56 msec 0 msec 3 192.168.100.1 [AS 65001] 4 msec 0 msec 4 msec
After restoration of the primary channel it is necessary to wait for some time (around 5 - 10 seconds) before Cisco finds out that the connections has been restored. This is indicated by the following log:
.Jan 2 13:33:15.448: %BGP-5-ADJCHANGE: neighbor 172.16.102.1 Up
As soon as the router detects the primary channel restoration, all traffic goes via this route that is shorter.
Sometimes using length of the route as the main selection criterion is not suitable. For example, you may have two Internet channels: a cheap primary channel, and an expensive reserve one, and at that the cheap channel is longer. What to do in this case? Setting route weights will help.
Let's set a higher weight for the long route in order to make it being used as the primary one. For this the following commands should be used:
! Enter BGP parameters edit mode router bgp 65003 ! Specify weights neighbor 172.16.101.2 weight 200 neighbor 172.16.102.1 weight 100
Now, in case when both channels are accessible, the router selects the longer route as it has the higher weight:
Router#traceroute 192.168.100.1 Type escape sequence to abort. Tracing the route to 192.168.100.1 1 172.16.101.2 0 msec 0 msec 0 msec 2 172.16.103.1 [AS 65002] 0 msec 56 msec 0 msec 3 192.168.100.1 [AS 65001] 4 msec 0 msec 4 msec
Very often it is necessary to restrict a list of routes obtained from a BGP unit. Indeed, any unit may declare that a certain subnet is accessible via it, at the same time not providing a real route to the mentioned network. This makes possible attack threats like «Denial of Service», spoofing and other attack types.
For protecting against these problems it is necessary to determine a degree of belief to each of the neighbor BGP units, and to limit accordingly a list of routes that will be obtained from such a unit. Other routes will be ignored.
Limitation of autonomous system number are set by using access lists by using the parameter as-path:
ip as-path access-list <identifier> permit <regular expression>
Here a regular expression sets a template for applying the rule. For example, for restriction of the autonomous system 65004 the expression be ^65004$.
Besides that, it is possible to add limitations for a subnet address by using the prefix-list parameter:
ip prefix-list <name> seq <number> permit <subnet address>
Where <name> is the name of address list, <number> is a serial number of a record in the list, <subnet address> is an address of the network and its mask.
Now it is necessary to attach the lists to a certain BGP neighbor. The keyword “in” in settings means that filtration rules are applied to addresses declared from the current router. In case of the keyword “out” is set, the filters are applied to addresses sent by us to the current router.
In the BGP parameters edit mode this can be done by the following commands:
! For limitation of autonomous systems neighbor <unit address> filter-list <ID of the rule> ! For limitation of the network prefix neighbor 10.1.2.4 route-map <route-map name> in
route-map <route-map name> permit 10
match ip address prefix-list <prefix-list name>
Let's check how this example can be realized on our stand. For that on the router 'streamer.netup' let's limit subnets obtained from the router 'amalfi.netup'. Let's permit declaring only the network 192.168.100.0/24 and for more clearness configure amalfi.netup for declaring a new subnet 10.20.30.0/24 that is fictive. For that on streamer.netup we change the configuration file /etc/quagga/bgpd.conf in the following way:
router bgp 65002 bgp router-id 10.1.2.8 network 172.16.100.0/24 network 172.16.102.0/24 network 172.16.103.0/24 neighbor 10.1.2.4 remote-as 65001 neighbor 10.1.2.4 route-map AMALFI in neighbor 172.16.102.2 remote-as 65003 neighbor 172.16.103.2 remote-as 65004 ! ip prefix-list AMALFI_IP_LIST seq 6 permit 192.168.100.0/24 route-map AMALFI permit 10 match ip address prefix-list AMALFI_IP_LIST
On amalfi.netup in the configuration file /etc/quagga/bgpd.conf we add exporting of a fictive network 10.20.30.0/24:
router bgp 65001 bgp router-id 10.1.2.4 network 192.168.100.0/24 network 10.20.30.0/24 neighbor 10.1.2.8 remote-as 65002
After applying the settings let's check which networks were declared from amalfi.netup. For that let's run the following commands on streamer.netup:
streamer# show ip route bgp
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route
B>* 172.16.101.0/24 [20/0] via 172.16.103.2, eth0, 00:02:20
B>* 192.168.100.0/24 [20/0] via 10.1.2.4, eth0, 00:02:24
As it was suspected the information about the fictive network 10.20.30.0/24 haven't passed into the routing data. At that information about the
network 192.168.100.0/24 remained without changes and is available in the list of routes.
BGP perfectly fulfils routing management tasks in global networks such as the Internet. Testing has shown a prompt hardware reaction on connection losses, and also a very flexible configurability. Such a capability as filtration of sent and received routes allows using BGP as a tool for optimization of Internet traffic routes.
According to this article it is very convenient to use BGP for ... reserving the Internet channel. Switching between a primary and a reserve channel happens very quickly, that minimizes delays in rendering of services, and clients of an ISP will highly appreciate the quality of service.
Quagga project Web site
http://www.quagga.net/
RFC 1771, “A Border Gateway Protocol 4
(BGP-4)”
http://www.ietf.org/rfc/rfc1771.txt
Semyonov U.A. «Internet Protocols», chapter devoted to BGP
http://book.itep.ru/4/44/bgp44114.htm
Todd Lammle, Sean Odom, with Kevin Wallace. «CCNP: Routing. Study Giude».
© 2001 SYBEX Inc.;
|
|
