Archive for the ‘Cisco’ Category

MPLS VPN Services

Tuesday, February 9th, 2010


This article with aim to take a in depth look at MPLS and explain how your packets get from one side of the MPLS cloud to another. Hopefully this will give you some perspective that will prove useful in troubleshooting issues in your own MPLS implementations.

Most enterprise engineers MPLS experience goes something like this: The company needs to connect the office in Miami and the office in London with the corporate headquarters office in Chicago. The VPN design needs to be flexible, and most importantly the network connecting all 3 sites needs to be full mesh. By this I mean to say that any office should be able to talk to any other office using this MPLS VPN. At this point you contact your MPLS provider and ask them to provision 3 MPLS links, 1 for each of the above mentioned offices. The MPLS Sales team puts you in contact with their engineering department and they ask you a couple questions that they need answered in order to properly provision your lines. the number one question that they ask is “How do you want to send us routes?”  now depending on the size of your organization and the dynamic or static nature of your network you can opt for several options here are 3 of the most common.

1. Static Routes

2. BGP Peering

3. OSPF Peering

Now if your network is very small, say for instance you have 3 shoe stores that need to talk to the corporate office / warehouse, then you might opt for the static route option. If you are a large organization that is publicly traded and has a robust network and security policy in place you will most likely choose the second option as this gives you the most security and control over what routes enter and leave your network.  However the third option is also very popular, mainly because many organizations are already running OSPF, so this makes it that much easier to peer with the ISP. However using the same IGP to peer with your MPLS provider as you use to run your internal networks does leave you at risk. There are a host of vulnerabilities OSPF has that could be exploited even if you are using OSPF MD5 authentication such as LSA injection attacks. However the biggest reason not to do this is that if the ISP makes a mistake they could inadvertently dump hundred or thousands of routes into your routing table which could destabilize your entire network.

Now wouldn’t you know after all that negative talk about ospf peering. The example I am going to talk about below is exactly that OSPF peering.

Please click on the above diagram for a larger view, you may want to download it as well and open it in a image view to zoom in on some of the smaller text and details.

In the example above you have 2 companies. To keep things simple we will call them Company A and Company B. Company A has 2 sites that need to communicate using MPLS, Company B also has 2 sites that need to communicate using MPLS. This ISP is lucky enough to get the business for both Company A and Company B. The ISP has a core network made up of an unspecified number of routers. In this example we will look at a small portion of the companies network. Our little piece of the network shows both customer sites connected to PE routers or (Provider edge) routers. These routers are responsible for providing access to the customers. The core of the network is made of P routers, or Provider routers. This provider has decided to convert their entire network to MPLS. This gives the ISP better performance by allowing the routers to utilize the ASICS built into the routers to switch the packets at incredible speeds. It also allows the ISP to offer many new services such as MPLS VPN’s as well as VPLS or (Virtual Private Lan Service.) In addition to these services the ISP can Use the tunneling aspect of MPLS to create Traffic engineering tunnels that will allow it to very precisely control which paths through the Provider network certain traffic takes. It also allows them to set very specific and granular QOS or COS policies for customers.

MPLS confuses many people because of its amorphous place in the OSI model. MPLs officially is a layer 2.5 protocol because Layer 3 protocols can be encapsulated in MPLS. MPLS stand for Multi Protocol Label Switching. MPLS can carry many different Layer 3 protocols inside it, just as ethernet a layer 2 protocol can carry TCP/IP inside its frames. However MPLS is more complicated than that. Many people can easily be confused because MPLs depends on the routing table in order to function, in this sense you could think of it like a layer 4 protocol. MPLS cannot function if the routing table is not working. MPLS depends on LDP or the Label Distribution Protocol to form adjacencies with neighbors and distribute its list of labels as well as receive labels from peers. LDP forms adjacencies at the layer 3 level and used the routing table to find peers. LDP is similar to OSPF in that is uses the highest Loopback address to identify itself. In our network Diagram each switch has a loopback address. All of the P routers including the PE routers are running OSPF. This OSPF instance is advertising the subnets owned by the ISP, many ISP’s use ISIS for this purpose, in fact many ISP’s use private addresses in their network especially if there network is a transit network. There are many situation in which you have public IP traffic traversing a private network connecting another public network. The 3 P routers and 2 PE routers need to know how to get to all of the non public IP addresses that the ISP is using to connect their network together. OSPF is used to synchronize these addresses as well as advertise each routers loopback address. Once all routers have formed neighbor relationships and all routes have been distributed through OSPF LDP is able to use the routing table to form adjacencies with other routers using their loopback addresses.

Once LDP has formed neighbor relationships with other routers using their loopback addresses it is able to start synchronizing the tag database. MPLS Assigns a tag or label to every route in the routing table. when a packet enters the MPLS PE routers interface, the router does a route lookup to determine the tag for the destination of the packet. Once this decision had been made, the router will push the tag on the packet and send it out the appropriate interface. The next router in line  has a simpler job. This router does not even have to look at the routing table, it can just look at its forwarding table and see what new tag should be assigned to the packet and send the packet on its way. the reason why this is so fast is because the MPLS tags were designed to look like layer 2 frames to the ASICS on the routers. This allows the programmers to leverage the same high speed chips used to route packets from one switch port to another based on mac addresses.

(more…)

Public DMVPN network.

Saturday, October 3rd, 2009

I was thinking about a new project idea. I was thinking of setting up a dynamic multipoint VPN concentrator. Put a small LAN behind it with a couple of servers. Put the configuration instructions on a webpage for Juniper and Cisco devices. I was thinking to run BGP routing protocol over the interface as it scales reasonably well.

The important part here is I wanted to create a web form which requests the internal and external address ranges of anyones network. Once that person submits that information I will have a Peal script pull those messages from the web form, parse the information, insert the networks and IP addresses into a J-Script template and apply it to my Juniper SRX router automatically.

This project will enable Cisco and Juniper students to participate in the environment and create a public VPN network where p2p APPS and anything else can run over the network without having to worry about any prying eyes. I want to see how far this project will scale. I was even envisioning a time when other people with idle equipment can volunteer to become a secondary hub to take some of the load once my connection reaches 10 thousand or so tunnels. Because of the way DMVPN works. The tunnels between sites will open up as needed when a user from site A needs to talk to site B. This combined with using BGP as the routing protocol will mean that it will require very little bandwidth as traffic destined from site A to C will not transit site B if site B in this scenario is the hub.

Anyways if anyone out there is interested please leave a comment.

Using IP SLA with Route-maps

Sunday, July 19th, 2009

I recently came across a problem that is not an uncommon problem that small businesses face. I came up with several solutions to their problems and I thought I would take a minute to discuss one of those solutions. This customer has a business requirement to use a proxy server for all outgoing web traffic. This on the face of it seems like a simple problem, there are many good proxy vendors out their such as my favorite vendor Blue Coat. There are many free alternatives such as Squid Caching Proxy server.
(more…)

Rotary Pools for Semi-Static NAT / Port range Forwarding

Monday, December 22nd, 2008

 

Cisco routers have a very robust network address translation feature set. The NAT software allows you to control translation with access-list, route-maps, and destination pools. With the wide array of commands, it is sometimes difficult for beginners and experts to figure out how to combine these elements to solve a problem.

 

 

 

 

 

 

 

(more…)

Content Based Access Control “CBAC”

Tuesday, October 21st, 2008

In the beginning God created heaven and earth, and then he created routers, so packets could flow from one part of the earth to the other. As he rested he looked down on his creation and smiled for all was good. Packets were flowing from one interface to another. Then as he beheld his creation he watches as some pad packets decided to flow where they didn’t belong! So God created access-lists and again everything was as it should be, packets only flowed to areas where they belonged. After some time naughty packets found out that they could sneak by God’s great protectors of the network by setting the ACK bit in their headers.

(more…)

Introduction to access-lists part 2

Thursday, October 16th, 2008

In the second installment of our guide to access-lists we are going to talk a little about named access-lists, how they work, what the benefits are, and how using them allows us to create reflexive access-lists. Named access-lists are exactly what they sound like, they are an extended access-list that has a name instead of a number. One of the nice features of named access-lists is that each line of the access-list has a number. this way you can delete just one line in an access-list without removing the whole access-list. You can create a named access list by using the following command.

(more…)

Introduction to access-lists part 1

Wednesday, October 15th, 2008

Today I would like to take some time and talk about security. I want to discuss access-lists, extended access-lists, reflexive access-lists, and CBAC or content based access control. Learning how to properly use access-lists is so crucial to becoming a good network administrator. They are vital to securing your network and as you progress with your studies you will find that access-lists are used quite extensively in routing, QoS, and other important things.

(more…)

Replace a running config without reloading!

Saturday, October 4th, 2008

The new Cisco IOS 12.4 train has many new features that any engineer will find useful; one of the features that fix a pain point for me is the new config options available in 12.4. Have you ever been in a situation where an entered configuration does not work as expected? Now usually you have to back out the configuration one command at a time and hope for the best. Sometimes you may even reach a point where you can not completely remove a configuration without reloading the device, this is the case sometimes when trying to remove sub interfaces. Now if this is a datacenter or work environment then you may not be able to reload the router.
  (more…)

Encrypting GRE tunnels!

Monday, September 8th, 2008

In our Last article we looked at creating GRE tunnels between networks to allow non-routable traffic to pass between remote offices.  GRE tunnels are a great solution however the traffic passing inside these tunnels is not encrypted and thus could be intercepted by unauthorized parties. In this article we are going to look at tunneling GRE inside of IPSEC. This will allow us to get the benefits of GRE and the security of IPSEC.

 

(more…)

Create a GRE tunnel between endpoints!

Monday, September 8th, 2008

Many time it is necessary to link a remote office to your main site and today we have many technologies to accomplish this task. We have IPSEC tunnels, IP-IN-IP tunnels, and GRE or Generic Routing Encapsulation Tunnels.

Each type of connectivity offers advantages and disadvantages. Some of these tunnels can even be overlaid on top of one another. For instance IPSEC can be used in a transport mode, which allows you to use the encryption with other tunnels or protocols. For this article we are going to discuss GRE tunnels. GRE is unique as tunneling technologies go in that is started out as a proprietary protocol developed by Cisco and later adopted as a standard. GRE was invented as a way of encapsulating non routable protocols in IP which is a routable protocol. In this way protocols such as multicast (this include OSPF, EIGRP), and other protocols like IPX could be tunneled across routable links.

  (more…)

Categories
Support Our site