Posts Tagged ‘BGP’
BGP+MPLS passed onto QoS!
Well I was finally able to sneak out of the office to go take the BGP+MPLS 642-691 exam earlier this week, something I have been trying to do for almost 2 weeks now. I really didn’t think finding the time to schedule the test was going to be the toughest part. The test took me an hour, and I passed so all my studying and work has paid off.
I was honestly a bit disappointed with the test, it seemed a bit more one-sided to me and the simulations were less than challenging in my opinion. I’ve done much more complicated labs in GNS3 and at work that matter. So as I was going the exam I felt more and more confident and really over-prepared. I do suppose it’s better than the alternative and failing the exam so I won’t dwell on this any further I passed and I am one step closer (well two technically) to getting my CCIP certification.
I’ll be jumping into QoS in hopes of taking this test by end of the year, and starting 2012 with my CCIP Certification!
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.
Watching BGP neighbors form.
BGP can be considered quite the routing protocol and typically tends to intimidate those that do not fully understand it. So I’m basically going to start from the ground up here and start from the forming of BGP neighbors.
Here is our topology, something nice and simple.
Now we are going to configure the BGP neighbor statements on our two routers.
While I run the debug ip bgp ipv4 unicast command on Router2:
From the debug output we see the two routers form a neighbor relationship as it goes through all of its phases.
- It starts from the Idle state, Idle is the phase that any BGP connection starts.
- Now you see move from Idle to Active in the Active state the BGP device is still trying to setup BGP session with its peer.
- Then you see we go from Active to OpenSent which shows we received a BGP Open message from the peer.
- Now continuing over the next few lines, you see this device sending out its Open message with its BGP version, AS number, and hold time. After that you will see the device receive an Open message from it’s neighbor and acknowledge its neighbor’s BGP capabilities.
- Now third line from the bottom we will see the status go from OpenSent to OpenConfirm, in this phase the BGP peers are simply waiting to receive a keep alive from the other.
- Then almost immediately we go from OpenConfirm to Established, and the BGP neighbor is up.
CCIE or Null! 