BGP Route Injection Script

BGP Route Injection Script

Maybe you’ll want to play with scaling of full feeds but you won’t setup a BGP-Session to your vital routing systems. On the other hand simulating a fullfeed takes some configuration time adding some hundred thousand routes on your testing equipment. That’s where bgp_simple enters the game.

It’ a BGP route injection script and it will take a file containing paths and routing-updates in bgpdump-format and inject these into an established BGP-Session. Take a Linux-System with Net::BGP installed and get a snapshot of a Remote Route Collector, e.g. from RIPE. The Script doesn’t have a config-file and takes parameters straight vom command line:


usage:
bgp_simple.pl: -myas ASNUMBER       # (mandatory) our AS number
               -myip IP address     # (mandatory) our IP address to source the sesion from 
               -peerip P address    # (mandatory) peer IP address
               -peeras ASNUMBER     # (mandatory) peer AS number
               [-holdtime] Seconds  # (optional) BGP hold time duration in seconds
               [-keepalive] Seconds # (optional) BGP KeepAlive timer duration in sec
               [-v[v]]              # (optional) verbose output to STDOUT
               [-p file]            # (optional) prefixes to advertise (bgpdump formatted)
               [-o file]            # (optional) write all sent and received UPDATE messages to file
               [-m number]          # (optional) maximum number of prefixes to advertise
               [-n IP address]      # (optional) next hop self, overrides original value
               [-l number]          # (optional) set default value for LOCAL_PREF 
               [-dry]               # (optional) dont build adjacency, but check prefix file (requ. -p)
               [-f KEY=REGEX]       # (optional) filter on input prefixes (requ. -p), repeat for # multiple filters  
                                     KEY is one of the following attributes (CaSE insensitive):
                                     NEIG    originating neighbor
                                     NLRI    NLRI/prefix(es)
                                     ASPT    AS_PATH
                                     ORIG    ORIGIN
                                     NXHP    NEXT_HOP
                                     LOCP    LOCAL_PREF
                                     MED     MULTI_EXIT_DISC
                                     COMM    COMMUNITY
                                     ATOM    ATOMIC_AGGREGATE
                                     AGG     AGGREGATOR
                                     REGEX is a perl regular expression to be expected in a match statement (m/REGEX/)

The file obtained from RIPE is in bgpdump-format, so you have to convert ist into something the script knows to handle. Just fetch bgpdump, compile it and use the routing snapshot from above. Add the resulting file containing the plain routing updates after the “-p” parameter together with the mandatory BGP-parameters. It’s just a matter how much RAM is installed in your gear. Set up a peering, don’t use MD5-protection as it isn’t supported and voi á la, you got the whole internet in a box. Two peerings on the same box for testing your MED-configuration (of course both peerings act individually, but you’re able to configure the local router side), or just feeding one central box to act as a route server, this script will provide you with the amount of data you’ve been looking for.

Attention: That’s live data with valid prefix routing information, so don’t take any actions letting your test equipment interact with live systems! Just said…

A private peering with the whole world on this single system isn’t something you’ll want to have. But it’s nice to play with, especially how many full feeds you’re able to handle. Only advertising of IPv4-Networks was tested. It’s slightly entertaining, watching a small 2960-Router at exploding after getting about 250.000 prefixes, paths and attributes. Maybe default-route would be better, but for that we won’t need that script, will we?

About Clemens

Got in touch with IT in the 80's, since then improving skills and following trends. Known as a disruptive reformer, exploring new ways to achieve goals, never satisfied with known ways for ages.

Comments