Archive for October 2011
BGP study notes posted.
I’ve updated my Study Notes page to include my BGP notes. Due to my recent job change I’ve found myself working much more closely with WAN Technologies QoS, BGP, IPSec, MPLS, EIGRP, OSPF Networks. So I figured CCIP level knowledge would very beneficial. My goal to take the BGP+MPLS 642-691 exam within the next month. Then hopefully pass the QoS 642-642 Exam before the end of year. I’m hoping to ring in the new year with a CCIP certification.
I’m using the following resources to study for the BGP+MPLS 642-691 Exam:
- Routing TCP/IP Volume II
- Internet Routing Archtitectures 2nd Edition
- BGP Design and Implementation
- MPLS Fundamentals
Scheduling router jobs utilizing Kron policies.
Another very nifty feature that is part of every router (along with Unix system) is the ability to run and schedule Kron jobs. The next question is what can you use these kron jobs for, well you can use them to run privileged level commands on a scheduled basis.
A few examples:
- Let’s say you want the router to automatically send it’s config to a TFTP or SCP server, create a kron job that will do just that on a weekly basis.
- Create a kron job that will write the running-config to memory so you don’t have to run the risk of losing your current configuration in the event of a power failure or router reboot.
- Set a kron job to run on a nightly basis and issue the undebug all command to prevent someone from letting a debug run rampant.
- The possibilities are almost endless.
Something to keep in mind however is the fact kron jobs cannot be used to make configuration changes, kron cli commands are submitted at the privilege level individually and because they are submitted individually you cannot nest commands to issue commands in global config mode. (You will want to look for a macro for something like that)
Now lets look at what we need to do to create and schedule a kron policy for a Cisco device:
- Create the kron policy.
- set the commands that are to be issued by the kron policy.
- Create the kron occurrence policy.
- Specify the re-occurrence schedule.
- Specify which kron policy to run under the occurrence schedule.
Setting up a kron policy
Setting the kron policy schedule.
The router will also tell you if the clock is not configured, as you could guess if the date/time on the router is not configured correctly scheduling the kron job could be difficult.
You can view the kron schedule by issuing the following command: sh kron schedule
Viewing the kron schedule
I’ve created a second schedule to run every 2 minutes to the sake of my own time.
You can also debug the kron job to verify it is running successfully: debug kron all
Kron debug output.
From the debug output you can see the router call the kron job, issue the command in the kron policy, delay the kron job another 2 minutes, and in this case you can see the router write config to memory.
Securing BGP.
BGP like other routing protocols need to be protected. Remember BGP runs off of TCP port 179 and because of this it is susceptible to the typical vulnerabilities of TCP, but we do have a few options that can be configured to provide some addition security.
1. MD5 Authentication
This should go without explanation like other routing protocols, neighbors will be authenticated using an MD5 key, this key must match on a per neighbor basis.
Configuring BGP Neighbor Authentication
Neighbor with a bad MD5 password
2. bgp maxas-limit
Maxas-limit doesn’t initially appear to apply any real security like the MD5 authentication, but the maxas-limit will prevent your BGP router from accepting routes with an AS-Path longer then the maxas-limit. This can help manage resources and prevent also prevent someone from pre-pending and AS-Path 20 AS’s long, which does not scale very well.
Sidebar history lesson: this feature came about after Cisco supported 4 octet AS numbers in the BGP packet (RFC 4893) because of a DoS vulnerability which has been fixed, but it still good practice to control the resources on your router.
Configuring maxas globally in config-router mode
maxas violation
3. TTL Security
TTL Security allows you to specify the packet TTL to eBGP neighbors, the reason this provides security is because it allows to specify how far away your peer is going to be. This will make it hard for someone to spoof a BGP neighbor that is further away then the configured TTL.
BGP TTL Security Configuration
4. Control Plane Policing – CoPP
Another option is to configure a service policy applied to the control plane so BGP updates are only processes from specific neighbors and not just anyone.
BGP Control Plane Policy
5. Limit the number prefixes you can learn from a neighbor.
This one you have to be careful with because when the prefix limit is reached the neighbor relationship is reset and re-established, obviously this will be production impacting. It can be configured to send a syslog warning message when the maximum prefix limit is reached, however it almost contradicts the purpose of configuring the maximum prefix.
Setting the maximum amount of prefixes BGP can learn from a neighbor
Now those are just a few ways you secure BGP in your network you can also filter BGP prefixes through a prefix-list, filter by ASPATH using regular-expressions, as well as using good old fashioned ACL’s. This Cisco page covers those addition BGP security configurations, and covers the ones I mentioned here.
CCIE or Null! 