CCIE or Null!

My journey to CCIE!

Archive for the ‘BGP’ Category

BGP study notes posted.

leave a comment »

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:

Not to mention a lot of hours labbing in GNS3.

Written by Stephen J. Occhiogrosso

October 24, 2011 at 7:30 AM

Securing BGP.

leave a comment »

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.

Written by Stephen J. Occhiogrosso

October 5, 2011 at 7:14 AM

Watching BGP neighbors form.

leave a comment »

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.

  1. It starts from the Idle state, Idle is the phase that any BGP connection starts.
  2. 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.
  3. Then you see we go from Active to OpenSent which shows we received a BGP Open message from the peer.
  4. 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.
  5. 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.
  6. Then almost immediately we go from OpenConfirm to Established, and the BGP neighbor is up.
To verify this we will issue the sh ip bgp nei summary command and verify the neighbor has been up for the last 5 seconds and no prefixes have been received. If the neighbor ship was not up then it would tell us the State of the adjacency (instead of the number of prefixes received).

Written by Stephen J. Occhiogrosso

September 6, 2011 at 6:43 AM