Route Server and Routing Registries
Over time, it became increasingly difficult to manage routing policies without a central database service. Starting from early approaches such as the NFSNET databases, today the Internet policies are stored in the Internet Routing Registry (IRR), which is a set of distributed databases. The Routing Assets Database (RADB) is the most prominent among them. Route servers are the regional entities that enforce parts of these policies on behalf of their EBGP route server clients. However, not all ISPs use them.
Requesting ASNs and IP Addresses
Suppose you work out your design and decide to request an ASN and a PI address block based on legitimate administrative requirements (for example, dual homing). Internet customers and subscribers are assigned IPv4/IPv6 addresses by ISPs and cannot directly approach registries. ISPs themselves obtain allocations from one of the following:
Internet Assigned Numbers Authority/Internet Corporation for Assigned Names and Numbers (IANA/ICANN) and its supporting organizations and delegates are in charge of domain name services, IP address services (including ASNs), and protocol number assignment services (http://www.icann.org, http://www.iana.net).
Five RIRs form the Address Supporting Organization (ASO) and have ICANN-delegated responsibility to ASNs and IP addresses:
NOTE
AfriNIC (http://www.afrinic.net) is the emerging organization that will be in charge of administering Internet number resources for the continent of Africa in the near future. At the time of this writing, they are finalizing their set of policies and expect to reach operational status soon.
Zebra Route Server with Multiple Views
A route server is commonly placed on a shared segment that resembles an exchange point. The purpose of the route server is to provide a single point of BGP signaling connectivity for all participants of the exchange to remove the need of any-to-any BGP peering setup. Thus, the route server and the exchange segment usually resemble a unique AS. The route server (europa) solely runs BGP for signaling purposes and does not get involved with forwarding real traffic and will never participate as a next hop. It just reflects EBGP announcements and acts as a central information repository.
Route servers are used to centralize routing and configuration functions and to collect Internet statistics. Zebra's bgpd does provide the capability to act as a route server via the neighbor route-server-client command. Together with its capability to use multiple views, it is a flexible engine for route server deployments.
Europa just runs bgpd, no zebra master daemon and no ospfd. It does not even require kernel IP forwarding to be turned on, or a default route (except for some minimal management access). A route server computes a collection of routes (a view) on behalf of each of its route server clients. A view is that part of a client's routing table that contains routes heard from other ISP routers at a NAP through a route server.
Most route server maintainers provide unprivileged Telnet or looking-glass access to their Zebra/Cisco nodes. Figure 10-10 simplifies the EBGP setup with the introduction of a route server (europa) running on OpenBSD 3.3. Figure 10-11 represents the physical layout.
reflects the configuration of the route server and the changed and simplified configurations for the route server EBGP clients. At the time of this writing, the route server feature of Quagga is evolving rapidly and might include features and extensions not covered here. Consult the Quagga mailing lists or source code for new features.
Example 10-21. Route Server/Route Server Client Configurations
europa-bgpd# show running-config Current configuration: ! hostname europa-bgpd password 8 m6eyKycFMHniQ enable password 8 bjYlnA9YLBWyM log file /var/log/bgpd.log service advanced-vty service password-encryption ! router bgp 65002 bgp router-id 192.168.14.3 bgp dampening neighbor RSERVER peer-group neighbor RSERVER soft-reconfiguration inbound neighbor RSERVER maximum-prefix 50 warning-only neighbor RSERVER route-server-client neighbor 192.168.14.1 remote-as 65000 neighbor 192.168.14.1 peer-group RSERVER neighbor 192.168.14.2 remote-as 65001 neighbor 192.168.14.2 peer-group RSERVER neighbor 192.168.14.254 remote-as 65003 neighbor 192.168.14.254 peer-group RSERVER ! access-list 1 remark vty-protection access-list 1 permit 127.0.0.1 access-list 1 permit 192.168.1.0 0.0.0.255 ! line vty access-class 1 exec-timeout 0 0 ! end callisto-bgpd# show running-config Current configuration: ! hostname callisto-bgpd password 8 m6eyKycFMHniQ enable password 8 bjYlnA9YLBWyM log file /var/log/bgpd.log service advanced-vty service password-encryption ! router bgp 65000 bgp router-id 192.168.1.1 bgp cluster-id 1.1.1.1 bgp dampening redistribute ospf neighbor INTERNAL peer-group neighbor INTERNAL remote-as 65000 neighbor INTERNAL route-reflector-client neighbor INTERNAL soft-reconfiguration inbound neighbor 192.168.2.7 peer-group INTERNAL neighbor 192.168.14.3 remote-as 65002 neighbor 192.168.14.3 soft-reconfiguration inbound neighbor 192.168.44.1 peer-group INTERNAL ! access-list 1 remark vty-protection access-list 1 permit 127.0.0.1 access-list 1 permit 192.168.1.0 0.0.0.255 ! line vty access-class 1 exec-timeout 0 0 ! end laurel# show running-config ... ! router bgp 65001 no synchronization bgp router-id 172.16.0.254 bgp cluster-id 1.1.1.1 bgp log-neighbor-changes bgp dampening network 172.16.0.0 mask 255.255.255.128 network 172.16.0.128 mask 255.255.255.128 neighbor 172.16.0.253 remote-as 65001 neighbor 172.16.0.253 soft-reconfiguration inbound neighbor 192.168.14.3 remote-as 65002 neighbor 192.168.14.3 soft-reconfiguration inbound maximum-paths 2 ! ... scar# show running-config ... ! router bgp 65003 no synchronization bgp router-id 10.0.0.1 bgp cluster-id 1.1.1.1 bgp log-neighbor-changes bgp dampening network 10.0.0.0 mask 255.255.255.0 network 10.0.1.0 mask 255.255.255.0 neighbor 10.0.1.2 remote-as 65003 neighbor 10.0.1.2 update-source Loopback0 neighbor 10.0.1.2 soft-reconfiguration inbound neighbor 192.168.7.7 remote-as 65000 neighbor 192.168.7.7 soft-reconfiguration inbound neighbor 192.168.14.3 remote-as 65002 neighbor 192.168.14.3 soft-reconfiguration inbound maximum-paths 2 ! ... callisto-bgpd# show ip bgp BGP table version is 0, local router ID is 192.168.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.0.0.0/24 192.168.14.254 0 0 65003 i * i 192.168.7.254 0 100 0 65003 i *> 10.0.1.0/24 192.168.14.254 0 0 65003 i * i 192.168.7.254 0 100 0 65003 i *> 172.16.0.0/25 192.168.14.2 0 0 65001 i *> 172.16.0.128/25 192.168.14.2 0 0 65001 i *>i192.168.1.0 192.168.2.254 20 100 0 ? *> 192.168.2.0 192.168.1.254 20 32768 ? * i192.168.44.0 192.168.2.254 20 100 0 ? *> 192.168.1.254 20 32768 ? *>i192.168.45.0 192.168.2.254 20 100 0 ? *> 192.168.80.0 192.168.1.254 20 32768 ? *> 192.168.99.1/32 0.0.0.0 10 32768 ? *>i192.168.99.2/32 192.168.2.7 10 100 0 ? * i211.11.117.0 192.168.2.254 20 100 0 ? *> 192.168.1.254 20 32768 ? Total number of prefixes 12 europa-bgpd# show ip bgp BGP table version is 0, local router ID is 192.168.14.3 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.0.0.0/24 192.168.14.254 0 0 65003 i * 192.168.14.1 0 65000 65003 i *> 10.0.1.0/24 192.168.14.254 0 0 65003 i * 192.168.14.1 0 65000 65003 i *> 172.16.0.0/25 192.168.14.2 0 0 65001 i *> 172.16.0.128/25 192.168.14.2 0 0 65001 i * 192.168.1.0 192.168.14.254 0 65003 65000 ? *> 192.168.14.1 0 65000 ? * 192.168.2.0 192.168.14.254 0 65003 65000 ? *> 192.168.14.1 20 0 65000 ? * 192.168.44.0 192.168.14.254 0 65003 65000 ? *> 192.168.14.1 20 0 65000 ? * 192.168.45.0 192.168.14.254 0 65003 65000 ? *> 192.168.14.1 0 65000 ? * 192.168.80.0 192.168.14.254 0 65003 65000 ? *> 192.168.14.1 20 0 65000 ? * 192.168.99.1/32 192.168.14.254 0 65003 65000 ? *> 192.168.14.1 10 0 65000 ? * 192.168.99.2/32 192.168.14.254 0 65003 65000 ? *> 192.168.14.1 0 65000 ? * 211.11.117.0 192.168.14.254 0 65003 65000 ? *> 192.168.14.1 20 0 65000 ? Total number of prefixes 12 europa-bgpd# show ip bgp summary BGP router identifier 192.168.14.3, local AS number 65002 6 BGP AS-PATH entries 0 BGP community entries Dampening enabled. Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.168.14.1 4 65000 74 66 0 0 0 00:00:38 8 192.168.14.2 4 65001 45 53 0 0 0 00:00:37 2 192.168.14.254 4 65003 49 47 0 0 0 00:00:35 5 Total number of neighbors 3
The Route Server Next Generation Project (RSng)
The Route Server Next Generation software (RSd, Route Server Daemon, http://www.isi.edu/ra/RSd/) was developed by the University of Southern California Information Sciences Institute (ISI) as their contribution to the Routing Arbiter Project, and later to RSng carried out together with Merit Network Inc. Merit Network provides the Routing Arbiter Database (RADB) as part of a distributed set of databases that form the IRR.
NOTE
The community still uses both expressions, Routing Arbiter Database and Routing Asset Database, when talking about the RADB.
IRRd is the routing database engine for RSng. Since the decommissioning of the NFSNET, these route servers have provided routing services to noncommercial NAPs (IXPs). The RSng service is by Merit Network Inc.
The RSd was derived from Merit GateD and designed to support BGP and provide SNMP support via the ISODE SMUX interface. The newest release of RSd does not install routes to the kernel forwarding tables per default. The configuration in Example 10-22 tries to mimic the Zebra route server setup in the previous example.
Example 10-22. RSd Configuration for Europa
autonomoussystem 65002;
routerid 192.168.14.3;
bgp yes {
# We do not want the RS to prepend its ASN in AS paths
# advertised to AS 65000, so we include the "transparent" clause.
group type external peeras 65000 {
peer 192.168.14.1 holdtime 180 transparent;
};
# We do not want the RS to prepend its ASN in AS paths
# advertised to AS 65001 and heard from AS 65000, so we include
# the "transparent 192.168.14.1" clause.
group type external peeras 65001 {
peer 192.168.14.2 holdtime 180 transparent 192.168.14.1;
};
group type external peeras 65003 {
peer 192.168.14.254 holdtime 180;
};
};
dampen-flap {};
# Following this, you would configure the views for different
# clients and the local view. The view descriptions are not
# required to be in any particular order. However, the import
# statements within a view are sensitive to order of specification:
# Routes are matched against import statements in the order specified.
# Note that we do not specify a view for AS 65000. This means
# that no routes are ever propagated by the RS to AS 65000.
# View for client AS 65001. # In this view, we install any route that matches
# the "import" statement shown.
view {
# This client has asked that the RS dampen route flaps on its behalf.
peer 192.168.14.2 preference 60 dampen;
# Import all routes heard from AS 65003 into this view.
#
import proto bgp as 65003 {
all;
};
};
# View for client AS 65003.
view {
# Never include any route advertised by AS 65003 in this view.
peer 192.168.14.254 preference 180;
import proto bgp as 65003 {
all restrict;
};
# Include those non-AS65003 routes that contain AS 32000
# in their AS path in this view.
import proto bgp as 65000 {
all;
};
};
Internet Routing Registries
The IRR is a collection of Internet routing policy databases that exchange or mirror routing information. These databases run Merit Network's IRRd as a database server and are populated with objects via the Routing Policy Specification Language (RPSL, RFC 2622), an evolution of the original RIPE design (RFC 1786/RIPE 181). Right now the first testbeds (for example, RIPE) for RPLSng (next generation) are emerging. RPSLng addresses the need for including routing policies for IPv6 and multicast address families and is currently based on two draft documents:
- draft-damas-rpslng-00.txt
- draft-blunk-rpslng-00.txt
The most prominent and oldest of these IRR databases is the Merit RADB. RADB mirrors the data of more than 30 other IRR object repositories. RADB objects are managed via e-mail or web form updates that support three types of authentication:
- Pretty Good Privacy/GNU Privacy Guard (PGP/GPG) keys
- Crypto-passwords
- Mail-From (mail header check)
IRRd originally was designed for the Routing Arbiter Project. It offers a Telnet Cisco-like command-line interface (CLI) and can be used as an integral part of the distributed IRR or as an independent local database server. IRRd can digest both RIPE 181 and RPSL routing registry syntax and perform conversion between these two representations.
A set of tools was designed to interface with IRRd and to provide policy analysis: the IRRToolSet, which is based on the RAToolSet (Routing Arbiter Toolset) developed by the USC Information Sciences Institute. The content of these databases can be used to create automated configurations and filter and access lists for route servers or peering routers (see Figure 10-12). Almost all Network Information Centers (NICs) offer sophisticated web interfaces as an alternative to traditional e-mail updates.
The Whois/Rwhois Interface
The whois protocol is used widely to query IRR databases and other Internet whois/nicname servers (see Example 10-23). Several tools exist that provide basic or enhanced whois client functionality:
- Traditional whois (RFC 954, "NICNAME/WHOIS"; comes with almost any system)
- Enhanced whois (http://www.linux.it/~md/software/)
- rwhois (supports the "referral" whois RFC 2167 v1.5 protocol, http://www.rwhois.net)
- GNU jwhois (http://www.gnu.org/software/jwhois/)
Example 10-23. Querying the IRR via the Whois Interface
[root@callisto:~#] whois -h whois.ripe.net help % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html % -lReturns first level less specific inetnum, % inet6num or route objects, excluding exact matches. % -L Returns all level less specific inetnum, % inet6num or route objects, including exact matches. % -m Returns first level more specific inetnum, % inet6num or route objects, excluding exact matches. % -M Returns all level more specific inetnum, % inet6num or route objects, excluding exact matches. % -x Requests that only an exact match on a prefix be % performed. If no exact match is found, no objects are % returned. % -c Requests first level less specific inetnum or inet6num % objects with the "mnt-irt:" attribute. % -d Enables use of the -m, -M, -l, and -L flags for lookups on % reverse delegation domains. % % -i Perform an inverse query. % % -F Produce output using short hand notation for attribute % names. % -K Requests that only the primary keys of an object be % returned. The exceptions are set objects, where the % members attributes will also be returned. This flag does % not apply to person and role objects. % -k (optional normal query) Requests a persistent connection. After % returning the result, the connection will not be closed by % the server, and a client may issue multiple queries on the % same connection. % Note that server implements 'stop-and-wait' protocol, % when no next query can be sent before receiving a reply % for the previous one. Use RIPE whois3 client to be able % to send queries in batch mode. % Except the first -k query, -k without an argument closes % the persistent connection. % -g (mirroring request) Request a NRTM stream from the server. % See [REF], section 4. "Mirroring the RIPE Database" for % more information." % % -R Switches off use referral mechanism for domain lookups, % so that the database returns an object in the RIPE % database with the exact match with the lookup argument, % rather than doing a referral lookup. % -r Switches off recursion for contact information after % retrieving the objects that match the lookup key. % -T (comma separated list of object types, no white space is allowed) % Restricts the types of objects to look up in the query. % -a Specifies that the server should perform look ups in all % available sources. See also -q sources" query. % -s (comma separated list of sources, no white space is allowed) Specifies % which sources and in which order are to be looked up when % performing a query. % % -q sources Returns the current set of sources along with the % information required for mirroring. See [REF], section % 2.9 "Other Server Features" for more information. % -q version Displays the current version of the server. % -t Requests a template for the specified object type. % -V Sends information about the client to the server. % -v Requests a verbose template for the specified object % type. % % [REF] RIPE Database Reference Manual. % http://www.ripe.net/ripe/docs/databaseref-manual.html [root@callisto:~#] whois -h whois.radb.net 193.154.180.0 route: 193.154.0.0/16 descr: Provider Local Registry Block descr: EUnet EDV und Internet Dienstleistungs AG descr: former KPNQwest Austria GmbH descr: former EUnet EDV-Dienstleistungs GmbH origin: AS1901 remarks: --------------------------------------- remarks: Please report abuse incidents like spam remarks: origination, network scanning etc to remarks: Abuse@EUnet-AG.at or +43 1 899 33 222 remarks: --------------------------------------- mnt-by: AS1901-MNT changed: chytil@Austria.EU.net 19960401 changed: Waldner@KPNQwest.at 20001204 changed: Rene.Avi@EUnet-AG.at 20030307 changed: Rene.Avi@EUnet-AG.at 20030606 changed: Rene.Avi@EUnet-AG.at 20031020 source: RIPE [root@callisto:~#] whois -h whois.radb.net AS1233 [whois.radb.net] aut-num: AS1233 as-name: ERX-NASDA-ASN descr: National Space Development Agency descr: Shiba-Ryoshin Building descr: 2-5-6, Shiba, Minato-ku descr: Tokyo 105 country: JP admin-c: JO71-AP tech-c: JO71-AP remarks: This aut-num object created as part of the ER-Transfer from ARIN mnt-by: MAINT-JP-NASDA changed: hostmaster@apnic.net 20020803 source: APNIC [root@callisto:~#] whois -h whois.radb.net AS1901-MNT mntner: AS1901-MNT descr: EUnet EDV Dienstleistungs AG descr: formerly KPNQwest Austria GmbH descr: formerly EUnet EDV DienstleistungsgmbH admin-c: OL122 tech-c: MD13304-RIPE tech-c: RA773-RIPE tech-c: TF5295-RIPE tech-c: AST2 tech-c: JH15046-RIPE tech-c: MM28666-RIPE tech-c: DK5882-RIPE upd-to: hostmaster@eunet-ag.at mnt-nfy: hostmaster@eunet-ag.at auth: CRYPT-PW bocEHQ0niH52I notify: hostmaster@eunet-ag.at mnt-by: AS1901-MNT referral-by: RIPE-DBM-MNT changed: Hostmaster@Austria.EU.net 19981104 changed: Waldner@KPNQwest.at 20010103 changed: Hostmaster@KPNQwest.at 20010510 changed: Rene.Avi@KPNQwest.com 20010607 changed: M.Mohler@KPNQwest.at 20010824 changed: Hostmaster@KPNQwest.at 20011106 changed: a.staunig@eunet-ag.at 20020808 source: RIPE [root@callisto:~#] whois -h whois.radb.net AS1901 aut-num: AS1901 as-name: EUNETAT-AS descr: EUnet Austria descr: former KPNQwest Austria descr: former EUnet Austria remarks: ------------------------------------------------------- remarks: Upstreams remarks: ------------------------------------------------------- import: from AS1273 action pref=80; accept ANY export: to AS1273 announce AS-EUNETAT import: from AS6461 action pref=100; accept ANY export: to AS6461 announce AS-EUNETAT import: from AS3561 action pref=100; accept ANY export: to AS3561 announce AS-EUNETAT import: from AS3257 action pref=100; accept ANY export: to AS3257 announce AS-EUNETAT remarks: ------------------------------------------------------- remarks: Customers remarks: ------------------------------------------------------- import: from AS5424 action pref=200; accept AS-VBSAT .... export: to AS21478 announce AS-EUNETAT import: from AS28685 action pref=100; accept AS-ROUTIT export: to AS28685 announce AS-EUNETAT import: from AS28788 action pref=100; accept AS-UNILOGICNET export: to AS-UNILOGICNET announce AS-EUNETAT import: from AS28836 action pref=100; accept AS-ICSNL export: to AS28836 announce AS-EUNETAT import: from AS28841 action pref=100; accept AS-MEGABIT export: to AS28841 announce AS-EUNETAT import: from AS29081 action pref=100; accept AS-WVNET export: to AS29081 announce AS-EUNETAT remarks: ------------------------------------------------------- admin-c: RA773-RIPE tech-c: IPEA1-RIPE remarks: ------------------------------------------------------- remarks: Communities for traffic engineering remarks: ------------------------------------------------------- remarks: 1901:11 Prepend (1x) to VIX remarks: 1901:12 Prepend (2x) to VIX remarks: 1901:13 Prepend (3x) to VIX remarks: 1901:15 Do not announce to VIX remarks: 1901:16 Prepend (1x) to AMS-IX remarks: 1901:17 Prepend (2x) to AMS-IX remarks: 1901:18 Prepend (3x) to AMS-IX remarks: 1901:20 Do not announce to AMS-IX remarks: 1901:21 Prepend (1x) to DE-CIX remarks: 1901:22 Prepend (2x) to DE-CIX remarks: 1901:23 Prepend (3x) to DE-CIX remarks: 1901:25 Do not announce to DE-CIX remarks: 1901:26 Prepend (1x) to LINX remarks: 1901:27 Prepend (2x) to LINX remarks: 1901:28 Prepend (3x) to LINX remarks: 1901:30 Do not announce to LINX remarks: 1901:81 Prepend (1x) to TINET-AS3257 remarks: 1901:82 Prepend (2x) to TINET-AS3257 remarks: 1901:83 Prepend (3x) to TINET-AS3257 remarks: 1901:85 Do not announce to TINET-AS3257 remarks: 1901:86 Prepend (1x) to C&W-AS1273 remarks: 1901:87 Prepend (2x) to C&W-AS1273 remarks: 1901:88 Prepend (3x) to C&W-AS1273 remarks: 1901:90 Do not announce to C&W-AS1273 remarks: 1901:91 Prepend (1x) to C&W-AS3561 remarks: 1901:92 Prepend (2x) to C&W-AS3561 remarks: 1901:93 Prepend (3x) to C&W-AS3561 remarks: 1901:95 Do not announce to C&W-AS3561 remarks: 1901:96 Prepend (1x) to Abovenet-MFNX-AS6461 remarks: 1901:97 Prepend (2x) to Abovenet-MFNX-AS6461 remarks: 1901:98 Prepend (3x) to Abovenet-MFNX-AS6461 remarks: 1901:100 Do not announce to Abovenet-MFNX-AS6461 remarks: ------------------------------------------------------- remarks: Communities for traffic origination remarks: ------------------------------------------------------- remarks: 1901:1 AS1901 originating routes remarks: 1901:2 AS1901 customers as in AS-EUNETAT remarks: 1901:3 AS1901 peers remarks: 1901:9 AS1901 upstreams remarks: 1901:996 received at LINX remarks: 1901:997 received at AMS-IX remarks: 1901:998 received at DE-CIX remarks: 1901:999 received at VIX remarks: 1901:3xxxx origin city w/ xxxx being the postal address remarks: ------------------------------------------------------- remarks: send peering requests to peering@eunet-ag.at remarks: ------------------------------------------------------- notify: Hostmaster@eunet-ag.at mnt-by: AS1901-MNT changed: Alexander.Staunig@eunet-ag.at 20021029 changed: Rene.Avi@EUnet-AG.at 20030224 changed: Rene.Avi@EUnet-AG.at 20030311 changed: Rene.Avi@EUnet-AG.at 20030317 changed: Rene.Avi@EUnet-AG.at 20030327 changed: Rene.Avi@EUnet-AG.at 20030402 changed: Rene.Avi@EUnet-AG.at 20030409 changed: Rene.Avi@EUnet-AG.at 20030414 changed: Rene.Avi@EUnet-AG.at 20030519 changed: Alexander.Staunig@eunet-ag.at 20030523 changed: Rene.Avi@EUnet-AG.at 20030523 changed: Rene.Avi@EUnet-AG.at 20030526 changed: Rene.Avi@EUnet-AG.at 20030526 changed: Rene.Avi@EUnet-AG.at 20030527 changed: Rene.Avi@EUnet-AG.at 20030527 changed: Rene.Avi@EUnet-AG.at 20030528 changed: Alexander.Staunig@eunet-ag.at 20030528 changed: Alexander.Staunig@eunet-ag.at 20030603 changed: Alexander.Staunig@eunet-ag.at 20030623 changed: Alexander.Staunig@eunet-ag.at 20030626 changed: Rene.Avi@EUnet-AG.at 20030710 changed: Rene.Avi@EUnet-AG.at 20030710 changed: Rene.Avi@EUnet-AG.at 20030721 changed: Rene.Avi@EUnet-AG.at 20030818 changed: Alexander.Staunig@eunet-ag.at 20030822 changed: martin.dirnhofer@eunet-ag.at 20030822 changed: martin.dirnhofer@eunet-ag.at 20040105 changed: martin.dirnhofer@eunet-ag.at 20040326 source: RIPE
Figures 10-13 and 10-14 provide examples for the modern RADB and RIPE web interfaces to IRR management. In addition, the traditional e-mail-based submission system can be used.
IRRd
IRRd is set up easily. For compilation and installation details, consult http://www.irr.net. The parameters of the irrd daemon itself and the important tools irrdcacher and irr_rpsl_submit are demonstrated in Example 10-24. irrdcacher is used to retrieve a copy of a IRR database. After successful retrieval, the database is kept current via a mirroring mechanism. The tool can convert between RIPE 181 and RPSL format. irr_rpsl_submit can submit RPSL-style data to IRRd servers.
Example 10-24. irrd.conf and irrdcacher Retrieval with RPSL Conversion
[root@callisto:~#] irrd -? irrd: invalid option -- ? Usage: irrd [-a turn on atomic transaction mode] [-d] [-f ] [-g ] [-l ] [-n do not daemonize] [-s ] [-u don't allow privileged commands] [-v verbose mode] [-w ] [-x cancel bootstrap missing DB auto-fetch] IRRd 2.1.5 [17Oct2002] compiled on May 3 2003 [root@callisto:~#] irrdcacher -? Unknown option: ? irrdcacher: unknown command-line option or missing flag parm! usage: /usr/local/sbin/irrdcacher [options] files... options: -p irrd port (default 43) -s ftp server and remote directory URL (default 'ftp://ftp.radb.net/routing.arbiter/radb/dbase') -w add component to your default search path -f full path name of the irrd.conf file (default /etc/irrd.conf) -S suppress the cache refresh signal to irrd -C do RPSL conversion example: /usr/local/sbin/irrdcacher -p 5555 radb mci RADB.CURRENTSERIAL special note: If you are running via cron be sure to use the '-w' flag [root@callisto:~#] irr_rpsl_submit -? irr_rpsl_submit: invalid option -- ? Usage: irr_rpsl_submit [options] [filename] -v verbose logging, turn on debugging -c (default 'foo') -E DB admin address for new maintainer requests -f (default '/etc/irrd.conf') -h (default 'localhost') -l (default 'irrd_directory') -p (default 43) -r (default is ~/.pgp) -s source is authoritative The file is chosen by irr_submit -R RPS Dist mode -D Inetd mode, read/write to STDIN/STDOUT -x do not send notifications The '-x' flag will cause updates to be sent to IRRd only. The default is to send all notifications. Command line options will override irrd.conf options. -F " enclosed response footer string. -O " enclosed host/IP web origin string. irr_submit compiled on May 3 2003
The daemon from Example 10-24 uses the default configuration file /etc/irrd.conf, as shown in Example 10-25.
Example 10-25. irrd.conf and irrdcacher Retrieval with RPSL Conversion
[root@callisto:~#] cat /etc/irrd.conf ##################################################################### # MRTd -- MRT version 2.1.5 [17Oct2002] ##################################################################### # debug all /var/log/irrd.log 0 irr_directory /var/spool/irr_database #irr_mirror_interval 1800 #irr_database radb mirror whois.radb.net 43 irr_database radb mirror_host 198.108.0.18 43 irr_database radb clean 172800 line vty login password cisco ! tmp directory /var/tmp db_admin gernot.schmied@iktech.net irr_mirror_interval 1800 irr_database iktech authoritative irr_database iktech clean 172800 irr_server localhost irr_max_connections 10 debug submission file-name /var/log/irr-submission.log override_cryptpw rTTLizvPtcv8Q [root@callisto:~#] irrdcacher –C radb RADB.CURRENTSERIAL Successful operation callisto IRRd# show database Listening on port 43 (fd=13) Memory-only indexing RPSL Syntax Default Database Query Order: radb iktech Database Size (kb) Rt Obj AutNum Obj Serial # Last Export # ------------- --------- ------ ---------- -------- ------------- iktech 1.2 0 5 0 radb 22686.9 68378 2480 183568 TOTAL 22688.0 68378 2485 iktech AUTHORITATIVE Last email/tcp update Never Last loaded 00:13:33 05/17/2003 Next dbclean in 37:19:01 radb Mirroring 198.108.0.18:43 (Next in 131 seconds) Last mirrored 00:33:23 05/17/2003 52 bytes, 0 change(s) Next dbclean in 60:02:02 callisto IRRd# show mirror-status radb radb (Mirror) Local Information: Oldest journal serial number: 181769 Current serial number: 183568 Remote Information: Mirror host: 198.108.0.18:43 Mirrorable. Oldest journal serial number: 177225. Current serial number: 183568. Last exported at serial number: 155408. [root@callisto:~#] ls -al /var/spool/irr_database/ total 27752 drwxr-xr-x 2 root root 4096 May 17 00:33 ./ drwxr-xr-x 24 root root 4096 May 11 18:34 ../ -rw------- 1 root root 5062 May 17 00:02 ack.log -rw------- 1 root root 0 May 16 23:38 ack.log.LOCK -rw-r--r-- 1 root root 1175 May 17 00:13 iktech.db -rw-r--r-- 1 root root 0 May 17 00:12 iktech.db~ -rw-r--r-- 1 root root 0 May 17 00:13 iktech.JOURNAL -rw-r--r-- 1 root root 29 May 17 00:33 IRRD_STATUS -rw-rw-rw- 1 root root 6 May 17 00:33 RADB.CURRENTSERIAL -rw-rw-rw- 1 root root 25187193 May 17 00:33 radb.db -rw-r--r-- 1 root root 3155326 May 17 00:33 radb.JOURNAL -rw-r--r-- 1 root root 52 May 17 00:53 .radb.mirror -rw------- 1 root root 2131 May 17 00:02 trans.log -rw------- 1 root root 0 May 16 23:16 trans.log.LOCK
Use irrdcacher to fetch an initial copy of the IRR databases. This might take a couple of minutes; don't interrupt the download. The RPSL version of the RADB is 23 MB long. From now on, mirroring updates the local database. After establishing a local authoritative server and database, you can query the local server via whois clients (see Example 10-26).
Example 10-26. Local IRRd Whois Query
[root@callisto:~#] whois -h whois.radb.net 193.154.180.0
route: 193.154.0.0/16
descr: Provider Local Registry Block
descr: EUnet EDV und Internet Dienstleistungs AG
descr: former KPNQwest Austria GmbH
descr: former EUnet EDV-Dienstleistungs GmbH
origin: AS1901
remarks: ---------------------------------------
remarks: Please report abuse incidents like spam
remarks: origination, network scanning etc to
remarks: Abuse@EUnet-AG.at or +43 1 899 33 222
remarks: ---------------------------------------
mnt-by: AS1901-MNT
changed: chytil@Austria.EU.net 19960401
changed: Waldner@KPNQwest.at 20001204
changed: Rene.Avi@EUnet-AG.at 20030307
changed: Rene.Avi@EUnet-AG.at 20030606
changed: Rene.Avi@EUnet-AG.at 20031020
source: RIPE
Figure 10-15 presents an architectural suggestion for a modern provisioning system in sync with the IRR.
The IRRToolSet
The IRRToolSet is a collection of RPSL-aware policy-analysis tools to improve the utilization of the information stored in the IRR. This toolbox contains the following useful tools:
- roe (Route Object Editor)
- aoe (Autonomous System Object Editor)
- CIDRAdvisor (suggests safe CIDR aggregates)
- prtraceroute (extended version of traceroute; displays autonomous systems)
- Prpath (full path between two autonomous systems)
- RtConfig (generates router configuration files)
- Peval (low-level policy-evaluation tool)
- Rpslcheck (RPSL syntax check for the aut-num object)
As a prominent example of these tools, look at the RtConfig tool via the RIPE web interface at http://www.ripe.net/cgi-bin/RtConfig.cgi to produce a Cisco configuration file (see Figure 10-16). You can deploy this configuration on BGP edge routers or route servers.
demonstrates the enhanced AS_Path capabilities of the prtraceroute utility. Figures 10-17 and 10-18 offer a quick impression of the aoe and roe graphical object editor approach of the IRRToolSet.
Example 10-27. prtraceroute Extensions to Regular Traceroute
prtraceroute to whois.arin.net (192.149.252.21), 30 hops max, 12 byte packets 1 [AS3333] ve01.homer.ripe.net (193.0.1.126) 5.718 ms 5.297 ms 3.931 ms 2 [AS3333] e11.pampus.ripe.net (193.0.6.9) 58.872 ms 8.394 ms 6.442 ms 3 [AS3333] fe20.marken.ripe.net (193.0.0.244) 6.897 ms 5.747 ms 5.123 ms 4 [AS1200] GigabitEthernet0-0-0.amsix1.ams1.level3.net (193.148.15.110) 3.756 ms 62.783 ms 5.724 ms 5 [AS9057] ge-4-3-0.mp2.Amsterdam1.Level3.net (213.244.165.2) 5.74 ms 138.052 ms 4.119 ms 6 [AS9057] so-3-0-0.mp2.London1.Level3.net (212.187.128.57) 42.934 ms 19.489 ms 9.607 ms 7 [AS9057] so-1-0-0.mp2.NewYork1.level3.net (212.187.128.153) 85.252 ms 124.122 ms 79
If You Enjoyed This Post Please Take a Second To Share It.
You Might Also Like
Stay Connected With Free Updates
 |
 |
 |
|
Subscribe via Email
|
