ShirazOnline
نمایش نتایج: از شماره 1 تا 4 , از مجموع 4

موضوع: Build a network router on Linux

  1. #1
    RezaBehroozi admin آواتار ها
    تاریخ عضویت
    Jan 1970
    محل سکونت
    Iran/Shiraz
    نوشته ها
    11,188
    تشکرها / پسندها

    پیش فرض Build a network router on Linux

    Zebra is open source TCP/IP routing software that is similar to Cisco's Internetworking Operating System (IOS). Flexible and powerful, it can handle routing protocols such as Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Border Gateway Protocol (BGP), and all of their various flavors. This article shows how our authors set up Zebra and used it to manage routes dynamically in conjunction with real Cisco hardware.
    Dynamic and robust routing is so essential to the workings of the Internet that any fledgling internetworking engineer must not only understand its concepts but also be able put it into practice in real situations. At the same time, this part of the routing scene is dominated by products from high-end network equipment providers such as Cisco, well outside the means of most individuals: learning would otherwise be limited to school or laboratory environments, with time and availability of the resources as perennial adversaries.

    We were faced with such a dilemma when organizing a class on TCP/IP routing. Working with a small test network, we wanted to demonstrate various load-balancing scenarios with Routing Information Protocol (RIP) and Open Shortest Path First (OSPF). However, we were limited by the number of Cisco routers on hand. We did have some PCs available, so we began looking for alternative means to simulate Cisco routers using Linux.
    Initially, we attempted to set up our test network using the traditional routed and gated daemons, but we quickly realized that their awkward configuration and limited capabilities created more hindrance than value. We decided to look for more modern means of completing our network and fortunately came upon Zebra.
    What is Zebra?
    Zebra is TCP/IP routing software that supports BGP-4, BGP-4+, OSPFv2, OSPFv3, RIPv1, RIPv2, and RIPng. It is distributed under the GNU General Public License and runs on Linux as well as other UNIX variants. Zebra is included in most modern distributions as routing software. The latest version, along with documentation, is available at the GNU Zebra Web site (see [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید] for a link).
    The original Zebra package was written by Kunihiro Ishiguro and Yoshinari Yoshikawa back in 1996. Today, the package is maintained primarily by IP Infusion -- of which Mr. Ishiguro is the CTO -- with the assistance of networking engineers and open source volunteers.
    Zebra is unique in its design because it takes a modular approach to the protocols that it manages. Protocols can be enabled or disabled as network requirements dictate.
    By far the most useful feature we found with Zebra was its close similarity to the Cisco IOS configuration formats. While there are some differences from IOS, the feel is close enough that network engineers already familiar with IOS will feel very comfortable in the environment.
    While Zebra has not yet hit version 1.0 -- the version at the time of this writing is 0.93b -- the quality of the product is adequate for small networks that need a core router. [Please note that this article was written using version 0.93b. Later versions may need to be installed and configured differently. -Ed.]




    [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید]



    Installing Zebra
    Our test platform for Zebra was an old but sturdy ThinkPad X20 running Red Hat Linux 9. The ThinkPad has a built-in Ethernet port, and we added another Ethernet PCMCIA card so it could act as a router. Before proceeding with the Zebra installation, we made sure that both network cards were recognized by Linux and were confirmed to be working.
    An RPM for Zebra-0.93b already ships with Red Hat 9. As this was the same version available on the Zebra Web site, we decided to use this instead of downloading and compiling our own. The Zebra RPM installs binaries, scripts, and configuration files as well as the requisite manuals, examples, and documentation files.
    Basic Zebra configuration
    The zebra daemon is the actual routing manager that controls the other modules; it also provides the primary point of interaction with the user. This was the first thing we needed to configure, and we did it through the /etc/zebra/zebra.conf file.
    The Zebra RPM package includes a complete sample configuration file. However, at a minimum, we really only needed to create a /etc/zebra/zebra.conf file containing the following lines:


    Listing 1. A minimal Zebra configuration file

    hostname speedmetalpassword zebraenable password zebra


    The hostname directive specifies the name of the router whenever you enter interactive configuration mode. It can be any label and does not necessarily have to correspond to the hostname of the machine.
    The password directive specifies the password for logging into the interactive Zebra terminal.
    The enable password directive specifies the password for a higher level of access to Zebra, when you want to make configuration changes.
    Having created the /etc/zebra/zebra.conf file, we could now start the zebra daemon by executing:
    # service zebra start
    We were now able to enter the Zebra interactive session by telnetting into port 2601 of our machine.


    Listing 2. A sample Zebra session

    [root@speedmetal zebra]# telnet 127.0.0.1 2601Trying 127.0.0.1...Connected to 127.0.0.1.Escape character is '^]'.Hello, this is zebra (version 0.93b).Copyright 1996-2002 Kunihiro Ishiguro.User Access VerificationPassword: zebraspeedmetal> enablePassword: zebraspeedmetal# ? configure Configuration from vty interface copy Copy configuration debug Debugging functions (see also 'undebug') disable Turn off privileged mode command end End current mode and change to enable mode. exit Exit current mode and down to previous mode help Description of the interactive help system list Print command list no Negate a command or set its defaults quit Exit current mode and down to previous mode show Show running system information terminal Set terminal line parameters who Display who is on vty write Write running configuration to memory, network, or terminalspeedmetal#


    Navigating within the interactive terminal is easy. For hints about the available commands, you can press ? at any time and the options will show on screen. If you're setting up your own Zebra router, this configuration should be very familiar if you have Cisco experience.
    At this point, only Zebra was configured and running; none of the other protocols were, as yet. Later, when we get to the meat of the configuration, we'll show you how we did that.
    Configuring and using MRLG
    The Multi-Router Looking Glass, or MRLG, written by John Frazier of EnterZone, is a Web-based utility that can be used to display the interfaces and routes recognized by Zebra. MRLG is really nothing more than a Web interface to the Zebra shell with a limited set of commands, but in the course of our testing, we found it to be a quick and useful way to display routes. So, before getting to the configuration of the Zebra protocols, we'll show you how we installed it.
    MRLG requires the Net::Telnet Perl package so that it can communicate with the Zebra shell. Unfortunately, this package is not included as part of the stock Red Hat 9 distribution, so we had to download it (see [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید] for a link).
    Since MRLG runs as a CGI application, we also needed to install a Web server. If you're trying this yourself, you can use the stock httpd RPM that comes with Red Hat 9.
    We copied the mrlg.cgi file from /usr/share/doc/zebra-0.93b/tools to /var/www/cgi-bin. Then, we modified line 36 of mrlg.cgi, changing it from:
    $url="http://www.sample.com/mrlg.cgi";
    to:
    $url="http://127.0.0.1/cgi-bin/mrlg.cgi";
    We also modified the block from lines 168 to 174 so that it read as follows:
    if ($Form{'router'} eq 'router1') {$server = '127.0.0.1';$login_pass = 'zebra';$bgpd = "2605";$zebra = "2601";$full_tables=1;


    To access MRLG, point the browser to [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید].


    Figure 1. The Multi-Router Looking Glass




    [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید]



    Basic lab configuration
    Our lab configuration consisted of two Cisco 3620 routers and a ThinkPad X20 with a built-in Ethernet port and a Home-and-Away PCMCIA Ethernet card. The two routers communicated with each other via serial connection, and each router connected to the ThinkPad through Ethernet. This is shown in our connection diagram:


    Figure 2. Lab connection diagram

    Setting up the interfaces with Zebra
    Our first foray into routing with Zebra started with RIP. We installed Zebra on the ThinkPad as described above. Since we needed another network interface on the ThinkPad, we installed a dummy network device like so:
    # modprobe dummy
    # ifconfig dummy0
    We telnetted into the Zebra port to begin configuration. Our dialog with Zebra followed this sequence:


    Listing 3. Configuring IP interfaces

    User Access VerificationPassword: zebraspeedmetal> enablePassword: zebraspeedmetal# configure terminalspeedmetal(config)# interface eth0speedmetal(config-if)# ip address 192.168.2.1/30speedmetal(config-if)# quitspeedmetal(config)# interface eth1speedmetal(config-if)# ip address 192.168.1.1/30speedmetal(config-if)# quitspeedmetal(config)# interface dummy0speedmetal(config-if)# ip address 10.0.2.1/24speedmetal(config-if)# writeConfiguration saved to /etc/zebra/zebra.confspeedmetal(config-if)# endspeedmetal# show run Current configuration:!hostname speedmetalpassword zebraenable password zebra!interface lo!interface eth0 ip address 192.168.2.1/30!interface dummy0 ip address 10.0.2.1/24!interface eth1 ip address 192.168.1.1/30!!line vty!end


    Take note that we did not set the IP addresses on the ThinkPad using the ordinary means; instead, we configured them through Zebra. The settings are kept in the configuration file, /etc/zebra/zebra.conf, so every time the Zebra service starts up, these settings will take effect.
    The contents of our zebra.conf file, as modified by Zebra, are:


    Listing 4. /etc/zebra/zebra.conf, as modified by Zebra

    !! Zebra configuration saved from vty! 2003/08/20 00:07:51!hostname speedmetalpassword zebraenable password zebra!interface lo!interface eth0 ip address 192.168.2.1/30!interface dummy0 ip address 10.0.2.1/24!interface eth1 ip address 192.168.1.1/30!!line vty!


    We are also able to check the status of the interfaces using MRLG by selecting the default, "router1," choosing the radio button "show interface," and clicking "Execute."




    [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید]



    Setting up RIP routing with Zebra
    Now that we had set up the network interfaces on our ThinkPad/router, we configured it to work with RIP updates. As we've already mentioned, Zebra implements the routing protocols using separate daemons, so we first had to create a simple configuration file, ripd.conf, for the RIP daemon in /etc/zebra.


    Listing 5. A basic /etc/zebra/ripd.conf file

    hostname speedmetal-rippassword zebraenable password zebra


    Then we started the ripd daemon:
    # service ripd start
    That done, we were able to configure the RIP daemon by telnetting into port 2602 of our Zebra router.


    Listing 6. Configuring RIP

    User Access VerificationPassword: zebraspeedmetal-rip> enablePassword: zebraspeedmetal-rip# configure terminalspeedmetal-rip(config)# router ripspeedmetal-rip(config-router)# network 10.0.0.0/8speedmetal-rip(config-router)# network 192.168.0.0/16speedmetal-rip(config-router)# endspeedmetal-rip# show runCurrent configuration:!hostname speedmetal-rippassword zebraenable password zebra!interface lo!interface eth0!interface dummy0!router rip network 0.0.0.0/0 network 192.168.0.0/16!line vty!endspeedmetal-rip# writeConfiguration saved to /etc/zebra/ripd.confspeedmetal-rip#


    The resulting ripd.conf configuration file is:


    Listing 7. Resulting /etc/zebra/ripd.conf file

    !! Zebra configuration saved from vty! 2003/08/19 13:50:30!hostname speedmetal-rippassword zebraenable password zebra!interface lo!interface eth0!interface eth1!interface dummy0!router rip network 10.0.0.0/8 network 192.168.0.0/16!line vty!


    Setting up RIP routing on the Cisco routers
    To facilitate configuration of the two Cisco 3620 routers, which we named "A" and "B," we configured only the basic settings needed to make the routers run properly. This included setting up the interface IP addresses, the loopback address, and the serial clockrates for proper serial port communication.


    Listing 8. Configuring router A

    Router#config terminalRouter(config)#hostname RouterARouterA(config)#int s0/0RouterA(config-if)#ip address 192.168.0.1 255.255.255.252RouterA(config-if)#no shutRouterA(config-if)# interface fastEthernet 0/0RouterA(config-if)#ip address 192.168.2.2 255.255.255.252RouterA(config-if)#no shutRouterA(config-if)#int loopback 0RouterA(config-if)#ip address 10.0.0.1 255.255.255.0RouterA(config-if)#endRouterA#write


    We followed a similar procedure for router B.


    Listing 9. Configuring router B

    Router#configure terminalRouter(config)#hostname RouterBRouterB(config)#int s0/0RouterB(config-if)#ip address 192.168.0.2 255.255.255.252RouterB(config-if)#no shutRouterB(config-if)#int fastEthernet0/0RouterB(config-if)#ip address 192.168.1.2 255.255.255.252RouterB(config-if)#no shutRouterB(config-if)#int loopback 0RouterB(config-if)#ip address 10.0.1.1 255.255.255.0RouterB(config-router)#endRouterB#write


    Setting up RIP on the 3620 routers is very similar to the commands in Zebra. We accessed both of the 3620s through the console cables and issued the following commands:


    Listing 10. Configuring router A for RIP

    RouterA#conf tEnter configuration commands, one per line. End with CNTL/Z.RouterA(config)#router ripRouterA(config-router)#network 10.0.0.0RouterA(config-router)#network 192.168.0.0RouterA(config-router)#network 192.168.2.0RouterA(config-router)#version 2RouterA(config-router)#endRouterA#write


    And, on router B:


    Listing 11. Configuring router B for RIP

    RouterB#conf tEnter configuration commands, one per line. End with CNTL/Z.RouterB(config)#router ripRouterB(config-router)#network 10.0.1.0RouterB(config-router)#network 192.168.0.0RouterB(config-router)#network 192.168.1.0RouterB(config-router)#version 2RouterB(config-router)#endRouterB#write


    The router rip command turns on the RIP process. The network command tells the router which networks will be propagated by RIP.
    Propagated routes with RIP
    Now that the Cisco routers and Zebra were all configured, we checked that the routes were being propagated. From MRLG, we selected "show ip route" and clicked "Execute." This generated the following report:


    Listing 12. Zebra reflecting RIP routes

    Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, B - BGP, > - selected route, * - FIB routeR>* 10.0.0.0/24 [120/2] via 192.168.2.2, eth0, 00:11:05R>* 10.0.1.0/24 [120/2] via 192.168.1.2, eth1, 00:02:08C>* 10.0.2.0/24 is directly connected, dummy0K * 127.0.0.0/8 is directly connected, loC>* 127.0.0.0/8 is directly connected, loR>* 192.168.0.0/30 [120/2] via 192.168.2.2, eth0, 00:11:05C>* 192.168.1.0/30 is directly connected, eth1C>* 192.168.2.0/30 is directly connected, eth0


    The routes learned through RIP are marked with an R.
    Note that Zebra now knew about the networks 10.0.0.0/24 and 10.0.1.0/24, as broadcast by router A and router B. We tested this by pinging 10.0.0.1 and 10.0.1.1 from the ThinkPad Zebra router, and by pinging 10.0.2.1 (the ThinkPad dummy interface) from either router.
    To test for route failover, we disconnected the network connection from router A, which led to network 10.0.0.0/24. After a total timeout of about two minutes, Zebra learned about the alternate route to network 10.0.0.0/24, going through router B. Note that in the listing below, Zebra reached 10.0.0.0/24 through 192.168.1.2 instead of its previous path.


    Listing 13. Zebra reflecting RIP routes

    Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, B - BGP, > - selected route, * - FIB routeR>* 10.0.0.0/24 [120/3] via 192.168.1.2, eth0, 00:00:26R>* 10.0.1.0/24 [120/2] via 192.168.1.2, eth1, 00:06:02C>* 10.0.2.0/24 is directly connected, dummy0K * 127.0.0.0/8 is directly connected, loC>* 127.0.0.0/8 is directly connected, loR>* 192.168.0.0/30 [120/2] via 192.168.1.2, eth1, 00:00:26C>* 192.168.1.0/30 is directly connected, eth1C>* 192.168.2.0/30 is directly connected, eth0


    Why was the total timeout more than two minutes? The default timeout for RIP is 30 seconds, but the RIP protocol specifies three retries (total of 90 seconds) before it determines a route is invalid and another period for flushing the invalid route (another 240 seconds). RIP has generally been known to be slow to responding to connection failures, and this behavior is clearly demonstrated here.
    Here is the output showing router A's routing table before failover occurred.


    Listing 14. Router A's routing table before failover

    RouterA#show ip routeCodes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static routeGateway of last resort is not set 10.0.0.0/24 is subnetted, 3 subnetsR 10.0.2.0 [120/1] via 192.168.2.1, 00:00:11, FastEthernet0/0C 10.0.0.0 is directly connected, Loopback0R 10.0.1.0 [120/1] via 192.168.0.2, 00:00:18, Serial0/0 192.168.0.0/30 is subnetted, 1 subnetsC 192.168.0.0 is directly connected, Serial0/0 192.168.1.0/30 is subnetted, 1 subnetsR 192.168.1.0 [120/1] via 192.168.0.2, 00:00:18, Serial0/0 [120/1] via 192.168.2.1, 00:00:11, FastEthernet0/0 192.168.2.0/30 is subnetted, 1 subnetsC 192.168.2.0 is directly connected, FastEthernet0/0


    And after failover:


    Listing 15. Router A's routing table after failover

    RouterA#show ip routeCodes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static routeGateway of last resort is not set 10.0.0.0/24 is subnetted, 3 subnetsR 10.0.2.0 [120/2] via 192.168.0.2, 00:00:09, Serial0/0C 10.0.0.0 is directly connected, Loopback0R 10.0.1.0 [120/1] via 192.168.0.2, 00:00:09, Serial0/0 192.168.0.0/30 is subnetted, 1 subnetsC 192.168.0.0 is directly connected, Serial0/0 192.168.1.0/30 is subnetted, 1 subnetsR 192.168.1.0 [120/1] via 192.168.0.2, 00:00:09, Serial0/0 192.168.2.0/30 is subnetted, 1 subnetsR 192.168.2.0 [120/2] via 192.168.0.2, 00:00:10, Serial0/0





    [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید]



    Setting up OSPF routing with Zebra
    Having done RIP, we moved on to OSPF routing. Although OSPF and RIP can be used together, we preferred to work with a simpler configuration and used OSPF exclusively. To disable RIP from Zebra, we simply shut down the ripd service.
    # service ripd stop
    As before, we started with a basic configuration file for OSPF, in this case, ospfd.conf, still in /etc/zebra.


    Listing 16. A basic /etc/zebra/ospfd.conf file

    hostname speedmetal-ospfpassword zebraenable password zebra


    Then, we started the OSPF service:
    # service ospfd start
    Configuring OSPF is actually simpler than configuring RIP: at the most basic, we only need to tell OSPF to broadcast all the routes it knows.
    The port for OSPF configuration is 2604.
    Here was our dialog for OSPF configuration.


    Listing 17. OSPF configuration dialog

    [root@speedmetal zebra]# telnet 127.0.0.1 2604User Access VerificationPassword: zebraspeedmetal-ospf> enablePassword: zebraspeedmetal-ospf# configure terminalspeedmetal-ospf(config)# router ospfspeedmetal-ospf(config-router)# network 0.0.0.0/0 area 0speedmetal-ospf(config-router)# endspeedmetal-ospf# writeConfiguration saved to /etc/zebra/ospfd.confspeedmetal-ospf# show run Current configuration:!hostname speedmetal-ospfpassword zebraenable password zebra!!router ospf network 0.0.0.0/0 area 0!line vty!endspeedmetal-ospf#


    The resulting configuration file, ospfd.conf, was:


    Listing 18. /etc/zebra/ospfd.conf as modified by Zebra

    !! Zebra configuration saved from vty! 2003/08/19 14:22:17!hostname speedmetal-ospfpassword zebraenable password zebra!!!interface lo!interface eth0!interface eth1!interface dummy0!router ospf network 0.0.0.0/0 area 0!line vty!


    Setting up OSPF on the Cisco routers
    To remove RIP from the routers and add OSPF, we executed the following commands:


    Listing 19. Removing RIP and adding OSPF

    RouterA#conf termRouterA(config)no router ripRouterA(config)#router ospf 100RouterA(config-router)#network 0.0.0.0 255.255.255.255 area 0RouterA(config-router)end


    We performed the same steps for both router A and router B.
    Propagated routes with OSPF
    Our MRLG report looked like this:


    Listing 20. Zebra reflecting OSPF routes

    Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, B - BGP, > - selected route, * - FIB routeO>* 10.0.0.0/32 [110/11] via 192.168.2.2, eth0, 00:00:01O>* 10.0.1.1/32 [110/11] via 192.168.1.2, eth1, 00:02:53O 10.0.2.0/24 [110/10] is directly connected, dummy0, 00:03:31C>* 10.0.2.0/24 is directly connected, dummy0K * 127.0.0.0/8 is directly connected, loC>* 127.0.0.0/8 is directly connected, loO>* 192.168.0.0/30 [110/58] via 192.168.2.2, eth0, 00:00:01 via 192.168.1.2, eth1, 00:00:01O 192.168.1.0/30 [110/10] is directly connected, eth1, 00:03:21C>* 192.168.1.0/30 is directly connected, eth1O 192.168.2.0/30 [110/10] is directly connected, eth0, 00:03:31C>* 192.168.2.0/30 is directly connected, eth0


    Note that the routes to 10.0.0.1/32 and 10.0.1.1/32 are marked with O, indicating that they were learned through OSPF.
    When we disconnected the connection from the Zebra router to router A, the routes were automatically updated. MRLG reported the following:


    Listing 21. Zebra reflecting OSPF routes after failover

    Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, B - BGP, > - selected route, * - FIB routeO>* 10.0.0.1/32 [110/59] via 192.168.2.2, eth0, 00:01:10O>* 10.0.1.1/32 [110/11] via 192.168.1.2, eth1, 00:09:46O 10.0.2.0/24 [110/10] is directly connected, dummy0, 00:10:24C>* 10.0.2.0/24 is directly connected, dummy0K * 127.0.0.0/8 is directly connected, loC>* 127.0.0.0/8 is directly connected, loO>* 192.168.0.0/30 [110/58] via 192.168.1.2, eth1, 00:01:10O 192.168.1.0/30 [110/10[ is directly connected, eth1, 00:10:14C>* 192.168.1.0/30 is directly connected, eth1O 192.168.2.0/30 [110/10] is directly connected, eth0, 00:10:24C>* 192.168.2.0/30 is directly connected, eth0


    Due to the link-state nature of OSPF, failover was much faster: the new routes were propagated in under 30 seconds.




    [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید]



    Summary
    We started out with a simple need to find a substitute Cisco router for our equipment-strapped networking class. Zebra was an intriguing option, one that had received good recommendations from reviewers on the Internet. As our testing shows, Zebra makes an adequate replacement for Cisco routers in simple networking environments, and possibly for some more complex installations as well.
    Admittedly, there was some degree of learning in going to Zebra. The use of separate routing daemons and separate configuration files was somewhat confusing at first, but after we had sorted that out, its general affinity to Cisco IOS immediately shone through.
    Overall, Zebra makes dynamic routing in a Linux environment a much simpler task. If you're ever in a situation where you need to set up a router quickly on a limited budget, you should give Zebra a try.




    [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید]



    Resources
    [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید]

  2. # ADS
    Circuit advertisement
    تاریخ عضویت
    Always
    محل سکونت
    Advertising world
    نوشته ها
    Many
     

  3. #2
    RezaBehroozi admin آواتار ها
    تاریخ عضویت
    Jan 1970
    محل سکونت
    Iran/Shiraz
    نوشته ها
    11,188
    تشکرها / پسندها

    پیش فرض

    [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید]
    [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید]

  4. #3
    RezaBehroozi admin آواتار ها
    تاریخ عضویت
    Jan 1970
    محل سکونت
    Iran/Shiraz
    نوشته ها
    11,188
    تشکرها / پسندها

    پیش فرض

    [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید]
    [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید]

  5. #4
    RezaBehroozi admin آواتار ها
    تاریخ عضویت
    Jan 1970
    محل سکونت
    Iran/Shiraz
    نوشته ها
    11,188
    تشکرها / پسندها

    پیش فرض

    [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید]

    If there is one thing I hate when reading a technical book, it's errors in the examples. A misplaced word or two in the text can be distracting, but in an example, it is often deadly. So when I set out to write BGP, I vowed to do everything I could to avoid this problem
    Unfortunately, there is no way to guarantee that errors weren't introduced during the later stages in the writing and publishing process, but as the writer, at least I could make sure the examples were correct when I put them in the manuscript. For this purpose, I had to create the actual configuration I wanted to use for each example, using my trusty-old Cisco 2500 at home. But I couldn't do this on a single router: I also needed BGP peers (neighbors) for my router to talk to. I had never been a great fan of host-based routers, but I figured anything that could talk BGP would do as something for my Cisco to talk to, at least for the basic examples. (Then I'd only need to scavenge routers elsewhere for the more complex ones.)
    Enter Zebra

    So, the first step was to install the Zebra routing software on my FreeBSD box. Zebra (the brainchild of Kunihiro Ishiguro) is a set of daemons, each implementing a single routing protocol. There are daemons for RIP, RIPng, OSPF, OSPFv6, and BGP, and an extra daemon called zebra that handles the interactions between the different protocols and the kernel routing table. The RIPng and OSPFv6 daemons support IPv6 routing within a single organization's [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید], and the BGP daemon implements the multiprotocol extensions in order to support IPv6 interdomain routing. (For more on IPv6, see Silvia Hagen's recently released book, [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید].)

    So does Zebra. (In both IOS and Zebra this behavior can be changed with the bgp bestpath med missing-as-worst command, to better conform to IETF guidelines.) This close similarity makes Zebra relatively easy to work with for someone who learned about routers on Cisco equipment (like me). Conversely, experience with Zebra is a good starting point when learning IOS. However, this doesn't mean Zebra is an "IOS emulator." Since Zebra just implements routing protocols and not the underlying packet forwarding, filtering routes is done differently than in IOS. Until a few years ago, Cisco only implemented two filtering mechanisms for packet filtering that can also be applied to route filtering: standard access lists and extended access lists. The syntax for using extended access lists to filter routes is rather convoluted. For instance, an extended access list that matches all routes with prefix lengths of 20 to 24 bits in 192.168.0.0/16 would be:
    access-list 169 permit ip 192.168.0.0 0.0.255.255 255.255.240.0 0.0.15.0
    Zebra's access list syntax is much simpler, but also less powerful:
    access-list test1 permit 192.168.0.0/16
    This matches 192.168.0.0/16 or any more specific prefix. The only other option is to use the exact-match keyword and then the access list line matches just 192.168.0.0/16 and nothing else. Fortunately, route filtering that uses access lists is a thing of past. IOS and Zebra now both implement prefix lists, which are as powerful as Cisco's extended access lists, but with the simplicity of Zebra's:
    ip prefix-list test2 permit 192.168.0.0/16 ge 20 le 24


    Zebra's Disadvantages

    As I became more familiar with Zebra, I grew more impressed by the software. Despite the fact that version 1.0 hasn't been released yet (only beta versions are available), I can't remember a single time when the software broke down. I can't say the same thing for the hardware: I had a hard disk crash on me. Fortunately, I had the foresight to install two hard disks and use disk mirroring with the vinum volume manager. The fact that they have hard disks has always been my biggest problem with host-based routers. Even if they don't crash (which they all do eventually), having a hard disk inside of a router means problems when the power fails: before you know it, your router is doing a file system check.



    "Real" routers aren't bothered by the power going away, since all of their software and configuration data is stored in flash or non-volatile memory. They don't even have a shutdown command, just a power switch. Just recently, I found out that it's fairly simple to have a Unix machine boot and run from flash memory. As it turns out, CompactFlash memory cards use an IDE interface. With the right converter, they can be attached to an IDE interface on the motherboard of a PC. The BIOS will then happily recognize the card as a hard disk and boot from it.
    Another thing that always used to worry me about host-based routers is IP forwarding performance. But some tests I did with Gigabit Ethernet cards in FreeBSD boxes convinced me that a PC-based system can handle several hundred megabits worth of data coming in or going out. Unfortunately, I was unable to fully test the routing performance due to lack of enough machines to act as source and sink for the necessary amounts of traffic. However, such a test between two boxes doesn't translate to good real-world performance as a BGP router. Currently, a full BGP feed is about 110,000 routes.
    Whether or not a system can achieve good forwarding performance with so many routes in its routing table is highly dependent on the route-lookup algorithm it uses for the majority of the forwarded packets. Cisco routers implement several ways to do this. In "process switching," a regular process reads a packet from the buffer where packets are stored as they come in, and then looks up the destination in the main routing table and schedules the packet for transmission on the right output interface. On a Cisco, this is slow. On a Unix machine, this would hardly work at all: the forwarding process would have to contend with other user processes for CPU time, and may even be swapped out to disk!
    Fast Switching Methods

    To increase forwarding performance, IOS implements "fast switching." This forwarding algorithm uses a route cache that stores the most recently used routes in a data structure that can be searched more efficiently than the main routing table. With fast switching, packets aren't stored in a buffer for further processing, but the forwarding algorithm is executed immediately as the CPU tends to the interrupt caused by the arrival of a packet. When the packet can't be fast switched because the destination can't be found in the route cache (or for another reason), it is handed over to regular process switching. As the packet is then process switched, a route cache entry is created so subsequent packets can be fast switched.
    An even faster switching method is Cisco express forwarding (CEF). CEF also operates at the interrupt level, but unlike fast switching, it employs a dedicated process for building the CEF data structures in memory. This CEF table holds a copy of the entire routing table, so there is no need to process switch the first packet towards any given destination.
    The fast switching route cache uses a radix tree structure to store next hop information (MAC address and output interface). Since an IP address has 32 bits, the radix tree has a depth of 32 levels, and looking up a route requires a maximum of 32 steps, assuming the right route is present. CEF, on the other hand, uses a 256-way trie structure. This makes it possible to search the tree in only four steps that each evaluate 8 bits in one go. And since the next hop information is no longer stored in the tree structure itself, there is additional flexibility. For instance, the CEF table can encode recursive routing information.
    So how is this done under Unix? Not all that differently: the 1990 4.3BSD-Reno interim release introduced a radix tree as the data structure for the kernel routing table. Thus, Unix IP forwarding is not quite as advanced as Cisco's CEF, but it improves on fast switching. This is because the radix tree holds the full routing table, so there is no need to rebuild it during process switching. So a Cisco will be somewhat faster than a Unix system with a similar CPU, but since in practice, Unix [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید] have much faster CPUs than Cisco routers, it more than makes up for the difference.
    A somewhat unfortunate similarity between Cisco and Unix is the size of these tables. On a Cisco, entries in the BGP table, the main routing table, and the CEF table all take roughly 100 to 300 bytes of memory per route. The FreeBSD kernel also uses nearly 300 bytes per route, as do the Zebra main routing table and the BGP table. (Note that on some systems, the kernel has a limit on the amount of memory that the routing table may use.)
    Summary

    All in all, I have to admit a Unix box running Zebra is a decent alternative to a "real" router. On the other hand, I still prefer the tight integration between hardware and software that router vendors offer, as long as their products aren't overpriced and underpowered. It's good to have choices.
    [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید] has been working with BGP in ISP and end-user networks since 1
    [فقط اعضا می توانند لینک ها را مشاهده کنند برای ثبت نام اینجا را کلیک کنید]

اطلاعات موضوع

کاربرانی که در حال مشاهده این موضوع هستند

در حال حاضر 1 کاربر در حال مشاهده این موضوع است. (0 کاربران و 1 مهمان ها)

موضوعات مشابه

  1. Using ISA Server 2006 to Extend Server and Domain Isolation Interoperability
    توسط patris_70 در انجمن ISA & Forefront Server
    پاسخ ها: 0
    آخرين نوشته: 2011/02/07, 11:48 PM
  2. Controlling Internet Access: a Short Primer on TMG Access Rules
    توسط patris_70 در انجمن ISA & Forefront Server
    پاسخ ها: 3
    آخرين نوشته: 2011/01/04, 11:44 PM
  3. Authenticate Linux Clients with Active Directory
    توسط patris_70 در انجمن Linux
    پاسخ ها: 0
    آخرين نوشته: 2010/07/04, 07:06 AM
  4. Connecting to Wireless Networks with Windows 7
    توسط patris_70 در انجمن Windows 7
    پاسخ ها: 0
    آخرين نوشته: 2010/07/04, 06:09 AM
  5. Bring your Network Closer to Five Nines with Graceful Shutdown
    توسط patris_70 در انجمن Cisco
    پاسخ ها: 0
    آخرين نوشته: 2010/04/15, 02:57 AM

علاقه مندی ها (Bookmarks)

علاقه مندی ها (Bookmarks)

مجوز های ارسال و ویرایش

  • شما نمیتوانید موضوع جدیدی ارسال کنید
  • شما امکان ارسال پاسخ را ندارید
  • شما نمیتوانید فایل پیوست کنید.
  • شما نمیتوانید پست های خود را ویرایش کنید
  •