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.

In MPLS the language is push and pop. to push a tag is to add a tag to a packet and to pop is to remove a tag from a packet.

Once MPLS is working the ISP can begin to configure its client connections. To do this the ISP creates two VRF tables (Virtual Routing forwarding). The first VRF table we will call CompanyA and the second VRF table we will call CompanyB. It is important to add 2 things to each VRF table. The first thing is the route-target and the second is the route-discriminator. The route target is used by BGP as an extended community attribute. This lets BGP and other protocols determine what routes should be added to a VRF instance, and it also lets BGP know what routes are from a VRF instance.

This is important, because we need a way to get the routes from Company A site 1 into Company A site 2 router without mixing them up with routes from any other client. This is one of the key factors that lets two way route redistribution function correctly.

Once the VRF is created the next thing to do is go to the interface that connects the customer and add that interface to the Companies VRF. Once you do this the connected route for that interface should no longer show up on the main routing table. Once this step is complete it is time to configure a second instance of OSPF to communicate with the CPE equipment. this is done by specifying the VRF name when creating the new instance of OSPF.

Now that the OSPF adjacency is up with the customer you should be able to see a list of the routes under that VRF. The next step is to establish a BGP neighbor relationship with the other PE routers in the ISP or a Route Reflector depending on the size of the environment. Once the BGP relationship is established, the only thing you have to do is redistribute the OSPF routes into BGP and vice versa under the appropriate OSPF Instance.

The end users should see the OSPF routes as simple IA routes. At the end of this post I will attach the full configs for all routers used incase you want to duplicate this in a lab or use GNS3 or Dynamips.

Routes as seen by end USER or MPLS Subscriber

Here are links to all the configs for all routers used in the lab –>Router Configs

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.

The most popular solution today is to use some sort of interception caching mechanism such as WCCP. Now WCCP is a Cisco protocol that has been more or less adopted by many other vendors even though the name is different foundry supports this protocol in their layer 4 switches, juniper supports it although under a different name, as well as HP switch and router products. The way WCCP works is to grab packets matching either an access-list or the built in web-cache group and forward those packets to the proxy, their by intercepting the packets as they reach the routed interface upstream from the end user. Now Cisco routers do this by creating a one-way GRE tunnel while Cisco switches perform this by using L2 redirects. If you are configuring WCCP on a Catalyst 6500 switch you have a choice of using L2 redirects or GRE tunnels.

The second most popular way to insure inform proxy setting across an enterprise is to use WPAD or (Web Proxy Auto Discovery Protocol) . Wpad works by writing a small JavaScript function in a text file, which tells the browser the proxy settings and what domains or subnets are excluded from the proxy such as local settings. Once you create your text file you save it to a web server on the local LAN in the root directory. An example would be http://webserver.mycompany.com/wpad.dat .

An example of the contents of the above file are as follows:

function FindProxyForURL(url, host) {
// our local URLs from the domains below example.com don't need a proxy:
if (shExpMatch(url,"*.techinvasion.local/*"))   {return "DIRECT";}
// URLs within this network are accessed through
// port 8080 on fastproxy.example.com:
if (isInNet(host, "10.0.0.0",  "255.255.255.0"))    {
return "PROXY proxy.techinvasion.local:3128";
 }
// All other requests go through port 3128 of proxy.example.com.
// should that fail to respond, go directly to the WWW:
return "PROXY proxy.techinvasion.local:3128; DIRECT";
}

The next step would be to add option 252 to the dhcp scope with an ASCII text entry of the web server path to the wpad.dat file as listed above. On a Cisco router with DHCP the entry would look like the following:

ip dhcp pool lan
     network 10.0.0.0 255.255.255.0
     update dns both
     domain-name techinvasion.local
     default-router 10.0.0.254
     dns-server 10.0.0.9 10.0.0.2
     option 252 ascii "http://stats.techinvasion.local/proxy.pac"
     lease infinite
 !

After this is done you should be in business. The only problem with this approach is that if you do not have active directory to force enable automatic proxy detection in internet explorer you really have no way to force users to look for this pac file. This can create uniformity problems and generate more calls to the help desk.

The final way we can configure the proxy is to use route-maps to redirect all web traffic to the proxy. The only problem with this approach is that if for some reason the proxy Is to go down the route-map will be directing traffic to a black hole! To remedy this we can use the IP-SLA feature to monitor the proxy and deactivate the route-map if the proxy is unavailable.

Now some things to remember, the route-map is only sending the traffic on port 80 to the proxy on port 80, if your proxy runs on a different port you will need to do a port redirect using ipfilter on FreeBSD based proxies, or ipchains on Linux based proxies to change the traffic to the correct port. Ok let get started with our configuration.

Step one create a http monitor that will use your proxy to pull an outside site like yahoo.com.

ip sla monitor 1
 type http operation get url http://www.yahoo.com name-server 10.0.0.9 proxy http://10.0.0.8/
 timeout 5000
!
ip sla monitor schedule 1 start-time now

The above code polls yahoo.com every 60 seconds to verify that the proxy server is working. Once you have that turned on you can issue the following commands to test it.

#sh ip sla monitor statistics 1
Round trip time (RTT)            Index 1
            Latest RTT: 266 ms
Latest operation start time: 04:19:13.020 edt Mon Jul 13 2009
Latest operation return code: OK
Latest DNS RTT: 0 ms
Latest TCP Connection RTT: 18 ms
Latest HTTP Transaction RTT: 248 ms
Number of successes: 55
Number of failures: 5
Operation time to live: 0

If you see:
Last operation return code: OK

Then that means everything is ok, it will say timeout if the proxy is down. Now I do the proxy test on port 80 because I want to verify that the ipchains port redirection rule is working as well, however you could specify a different port such as 3128 or 8080 if you wanted to.

The next step is to build the route-map and the track object. The track object is what the route map references to check availability of the next hop, in this case the next hop is the proxy. You setup as track object as follows.

Track option1 option2 option3

Option 1
(<1-500 > Tracked object)

Option 2
(interface Select an interface to track)
(ip IP protocol)
(list Group objects in a list)
(rtr Response Time Reporter (RTR) entry)

Option 3
(<1-2147483647> Entry number) ß this refers to the monitor number in the IP SLA command

In our case we want a response time reporter because we are interested in up/down information about the proxy.

track 1 rtr 1

Now we need to build and apply the route-map. First we need to build an access-list to specify the interesting traffic the route-map will be forwarding.

ip access-list extended proxy
10 deny ip host 10.0.0.8 any
! Block proxy traffic, we do not want to create a routing loop.
20 permit tcp 10.0.0.0 0.0.0.255 any eq 80

Here is the appropriate route-map below

route-map proxy permit 10
 match ip address proxy
 set ip next-hop verify-availability 10.0.0.8 1 track 1

To test this we can issue the command

#show route-map proxy
route-map proxy, permit, sequence 10
  Match clauses:
    ip address (access-lists): proxy
  Set clauses:
    ip next-hop verify-availability 10.0.0.8 1 track 1  [up]
  Policy routing matches: 41673 packets, 6145267 bytes

You will notice the “UP” this means that it sees our track object and it is getting th response time code from the ip sla monitor that we setup.

Juniper is also big on naming things, in JUNOS everything has a name, the Filter Lists have names, the terms in the Filter Lists have names, and even the address’s you are matching on have names. This is a big concept in JUNOS because it allows you to write snippets of Filter-Lists and use them for many different Filter Lists. JUNOS also supports grouping Filter Lists and applying an entire group of filter to an interface. If you apply Filter groups to a JUNOS interface they individual Filter Lists are evaluated in order sequentially.

To facilitate out discussion of Filter-Lists let’s take a look at a standard anti-spoofing access list which would be applied to most edge routers. First let’s talk about what a vanilla anti-spoofing ACL should contain! A standard ACL at a minimum should block all RFC-1918 address space from the internet, it should also block undesirable types of ICMP traffic, and depending on the setup should block packets with illegal combinations of TCP flags set, for example packets with the SYN-FIN flag set at the same time or FIN-URG-PSH or URG-ACK-PSH-RST-SYN-FIN at the same time. All of these combinations of TCP flags are illegal and should never be together as part of a legitimate packet. So without further ado lets talk about Filter Lists.
Filter Lists are defined under the Firewall section of the JUNOS configuration. Prefix Lists which are groups of networks, IP address ranges, or single hosts such as 1.1.1.1/32 are defined in these lists. These lists can later be used in as many Filter Lists as you define.

Below I will show you the actual Filter Lists as it looks in the configuration and some of the commands to create the list. For brevity I have opted to only show some of the commands used in creating the list as they are basically repetitive. The important thing to remember is that like all Access-Lists the terms in the Filter List are evaluated from top to bottom so it is important that the last term be an allow all statement otherwise the anti-spoofing filter will block all communication even legitimate communication.

[edit]
john#set policy-options prefix-list rfc1918-prefix-list 192.168.0.0/16

[edit]
john#set policy-options prefix-list rfc1918-prefix-list 172.16.0.0/12

[edit]
john#set policy-options prefix-list rfc1918-prefix-list 10.0.0.0/8

[edit]
john# edit firewall

[edit firewall]
john# edit filter anti-spoofing

[edit firewall filter anti-spoofing]
john# edit term block-rfc1918

[edit firewall filter anti-spoofing term block-rfc1918]
john# set from source-prefix-list rfc1918-prefix-list

[edit firewall filter anti-spoofing term block-rfc1918]
john# set then log discard

[edit]
john# show policy-options

prefix-list rfc1918-prefix-list {
    10.0.0.0/8;
    172.16.0.0/12;
    192.168.0.0/16;
}

[edit firewall]
john# show

filter anti-spoofing {
    term block-rfc1918 {
        from {
            source-prefix-list {
                rfc1918-prefix-list; ## 'rfc1918-prefix-list' is not defined
            }
        }
        then {
            log;
            discard;
        }
    }
    term block-fin-urg-psh {
        from {
            protocol tcp;
            tcp-flags fin,psh,urg;
        }
        then {
            log;
            discard;
        }
    }
    term block-syn-fin {
        from {
            protocol tcp;
            tcp-flags fin,syn;
        }
        then {
            log;
            discard;
        }
    }
    term block-urg-ack-syn-fin-rst-psh {
        from {
            protocol tcp;
            tcp-flags urg,ack,psh,rst,fin,syn;
        }
        then {
            log;
            discard;
        }
    }
    term block-icmp {
        from {
            protocol icmp;
            icmp-type-except echo-reply,unreachable,source-quench,time-exceeded;
        }
        then {
            log;
            discard;
        }
    }
    term accept-all {
        then accept;
    }
}

Remember to apply the Filter-List to the interface with the following command:

[edit]
john#set interfaces fe-0/0/0.0 family inet filter input anti-spoofing

Here is a related Article on ACL’s

I also discovered that Dove-net and Fido-net are still alive and well, and there are a great many BBS’s connected all over the world. If the internet is a vast global city such as Coruscant (in Star Wars) then BBS’s and protocols such as telnet and gopher are its seedy underworld. An eclectic grouping of forgotten protocols running on forgotten systems, used by a hand full of lost souls who still cling to the web as it was. I had allot of fun setting up this BBS and I would like to use it in some way as a fun addition to part of my site.

In the spirit of the above and to old memories and a simpler if not better time I want to announce that telnet://bbs.techinvasion.net is open for business, with door games and all. Accounts are free, and I have even put up a forum for people to request firmware and various other things that they might need for a networking project. I hope everyone has as much fun using the system as I had creating it and I hope to see everyone in a session of Trade Wars.

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.

GRE offers several advantages today when used as a tunnel to connect private LANs. The main advantages are the ability to carry multicast traffic, i.e. routing protocols across the internet. For instance, lets say you had a main office in London, which has Frame Relay links to 15 offices in Europe, and you have your headquarters in Washington D.C. with a MPLS network of 25 offices across North and South America. Now suppose due to the costs of bandwidth and particularly the cost of private connection such as frame across the pond, you decided to go with a 45mbps T3 line. Between London and D.C.  Now you could connect these offices with an IPSEC VPN however if you did this you would be limited to building static  routes for each network on each side of the ocean, this is not a very scalable solution and does not allow you the advantages of a dynamic routing protocol. This solution may even limit you should you decide to add a second T3 later say to an office in Madrid. With dynamic routing protocols, the traffic would automatically swing to the Madrid office if something were to happen to the link between D.C. and London. The solution  to this problem is to use GRE tunnels, since GRE tunnels pass all types of traffic you can easily run a dynamic routing protocol, like OSPF or EIGRP. These protocols will allow seamless easy route adjustments when a route goes down.

Configuring GRE tunnels is easy with a few simple steps you will be on your way. Before we can talk about configuring GRE tunnels we need to discuss exactly what the requirements for GRE are! GRE is a protocol, like IP you need to make sure this protocol is allowed through your firewall if you want to terminate a GRE tunnel. GRE to be more exact is protocol 47. Please be mindful that this is not port 47 but protocol 47. Allowing port 47 through your firewall will not allow GRE to work.

Steps to configure a GRE tunnel

1. create access-list on outside interface to permit GRE
2. create tunnel interface

interface Tunnel0
 ip address 172.20.1.1 255.255.255.252
 keepalive 10 3
 tunnel source FastEthernet0/0
 tunnel destination 192.168.1.2
 tunnel path-mtu-discovery
!
!
!
!
interface FastEthernet0/1
 description LAN INTERFACE
 ip address 10.0.0.254 255.255.255.0
 ip nat inside
 duplex auto
 speed auto
!
!
!
!
interface FastEthernet0/0
 description Internet Interface
 ip address 192.168.1.1 255.255.255.0
 ip access-group allow-gre in
 ip nat inside
 duplex auto
 speed auto
!
!
!
!
ip access-list extended allow-gre
 permit gre any any