Studyin' Foolio I am!!

I haven't posted in a few days so I figured it was time to update on some of my progress.I have been a studying fool lately to say the least. The topics I have covered over the last few days have been:

• Security (Standard ACL's ,Extended ACL's, Lock N Key Dynamic ACL's, Reflexive ACL's, TCP Intercept, 802.1x Authentication, and Storm-control.
• 802.1q tunneling a.k.a Q-in-Q tunneling.
• OSPF Filtering (Stub area, totally stub area, not so totally stubby area, and not so stubby area ( no im not being silly, they actually use these terms!!!)

I am going to start something new today. In some of my previous posts I went back and reviewed my notes and then wrote what I learned directly from my notes or from Cisco Documentation from the Doc CD. Today I am going to write about everything I learned about above from my own memory as I think this will be more beneficial for me in the long run. It will also point out to me technologies that I need to get stronger in if I am going to be successful in achieving my CCIE # in the routing & switching track. So here we go!

I will start with the access-lists. An access-list is a way to alllow or deny access to certain hosts/subnets. There are a few different ways we can go about this.

With a standard access-list we can allow or deny access to a host or subnet , but we can only do so with using the source IP address. This means I can only use the IP adress of the traffic that is coming towards me.

With an extended access-list I have much more granular control. I can filter based on source, or destination as well as: (specific port #'s, a range of port #'s, match protocols etc) I Won't go into to much more detail on this as this is pretty basic. Even though I knew the details of standard and extended access-lists before, it never hurts for a quick refresher.


Next on the list is Lock & key Dynamic Access-lists(ACL's). This topic was new to me so it was really fun learning about it. Basically you would configure this type of ACL when you want to punch a temporary hole in your router/firewall to allow access to a certain host/subnet, but doing so dynamically. For example, lets say you want to force a user to authenticate before being able to access the internet. You would first create an access-list allowing telnet traffic to the router because that is how the user will authenticate. You will need to have local authentication configured on the router that the user will need to authenticate against. If the user passes authentication the router will close the session, and add that specific users host address to be permited to access the internet dynamically. If you do a show access-list on the router you will see it dynamically updated the ACL to allow that users IP address to go out to the internet. I believe there are some timeouts that you can configure on this. This doesn't seem to practical in today's world, I think you would be better of using a proxy server honestly, but for the purposes of becoming CCIE this is something I need understand and be able to configure.

Next on the List is Reflexive ACL's. Now this is a feature I think would be seen in a real world implementation. This technology is a subset of the CBAC (content based access control)firewall feature set in IOS (Cisco's router/switch software Internetwork Operating System). Basically it will add stateful inspection to the ACl's. I believe you can only use Reflexive ACL's on internal network traffic. Here is how it works.Basically this allows us to automatically permit traffic that we have defined in our ACL's to re-enter our network automatically in its return path back to our internal network. First we would define that traffic we want to reflect, and we would apply it on our outbound(outside) interface , i.e:

- Ip access –list extended OUTBOUND

Permit tcp any any reflect STATEFUL

Permit udp any any reflect STATEFUL

Then we create another access list like below to "evaluate" the traffic coming back in to see if it was traffic we wanted to see the stateful information on.

- Ip access-list extended INBOUND

Evaluate STATEFUL

Deny ip any any(implicit)

You notice at the end of the last ACL the statements "Evaluate Stateful, followed by Deny ip any any"

This is very significant as we are only permitting traffic coming back into our network that is evaluated from our outbound ACL previously configured. All other traffic will be denied and will not reach our internal network.

I just realized on my previous topic I went overboard on the description. I cant be spending my time bloggin in such detail, I need to spend more time studying HAHA!!
So my Next Topic is TCP Intercept. This is a pretty cool feature. This feature is implemented as a way to protect against a TCP Denial of service attack to a Server hosting a TCP type protocol (web server, ftp server).It happens way to often where someone will send continuous "SYN" Packets to a server trying to establish a connection, however the destination address is not reachable so the server is not able to send a "SYN Acknolwedgement packet back. Eventually, there are a ton of half open non-established TCP sessions which will overwhelm the server and take it down making it unreachable and unable to provide its normal server services. Basically we can configure TCP intercept in two modes.

Intercept mode:

Intercept mode will force the router to act as a proxy between the external host sending the SYN Packet and the TCP server. So if someone wants to establish the 3-way TCP handshake, it will do so with the router. If the connection is established, the router will then merge the TCP conversation with the server and all is good!. However, if the router is sending SYN Ack's back to the host and the connection is not established, the router will not allow that host to talk to our TCP server! Pretty damn cool way to protect our server, However, Now the router will be overwhelmed by half open TCP sessions. We helped the server, but killed ourselves in this process :(

Watch Mode:

This is the best way to go about this in my opinion. The router will passively track the TCP connections and will drop the connection after it sees a certain amount of half open sessions. You can define this in the configuration thresholds.


Next on the list is Storm-control. Storm-control is pretty straightforward. You can limit the # of Unicast,Broadcast, or multicast packets that you want your switch interface to receive over a specific time period. You can do so in a few ways. You can limit the traffic in a PPS (packet per second rate) or by limiting the traffic to a percentage of the interface bandwidth.

Next on the list is 802.1q tunneling or Q-in-Q tunneling. This is used to transparently create a VPN across a switched ethernet network. Normally you will only see this in service provider aka ISP networks. Basically how it works is you create a "transit vlan" on the service provider edge switches between the two end point switches that you want to establish the VPN on. Then on the customer edge switches, you configure the VLAN's and trunks etc. The two end customer devices will now be able to communicate transparently over this tunnel You can also configure this to allow Spanning-tree, cisco discvoery protocol , and VLAN trunking protocol to run over this tunnel. *** Note be careful when configuring this on a switch if the switch is running OSPF routing protocol. In order for Dot1q tunneling to work correctly you need to change the system mtu to 1504 from the default of 1500 because of the extra dot1q tag added to the header. With OSPF if the MTU on neighboring OSPF speaking devices do not match, they will not form an adjacency. So as a workaround you can go on the switch and configure IP OSPF MTU-Ignore so the adjaceny will not be affected, and your OSPF will function as it normally did prior to configuring dot1q tunneling.

Lastly, is OSPF Filtering!! OSPF can get pretty crazy, but I think its my favorite routing protocol in the IGP Family. OSPF is a link-state protocol. When OSPF speaking devices form a neighbor relationship aka Adjacency they send each other their link state databases. Once all OSPF speaking routers have an identical copy of the link state database, they run the SPF(shorest path first algorithm) to find there best routes to each destination advertised. So, with that being said, the link state database can get big and can be processor intensive. Thankfully, there is a way to help shrink these Link state databases via OSPF filtering.

There are a few days to filter link state databases. But, today I will only mention one of them. There are several different types of area's we can configure to filter listed below:

Stub area - This will filter all LSA type 5's. Since these are filtered we will no longer see any External O E1, or O E2 routes in our OSPF routing table, the area border router (ABR) will install a default route in our routing table to reach these external prefixes.

Totally Stubby area - This will filter all LSA type 3, and LSA type 5's. The ABR will install a default route in the OSPF routing table to reach all internal and external prefixes.

Not so stubby area - this removes external LSA Type 5's from our link state database. The ABR does not originate a default route (area * nssa default-originate). This allows for redistribution into NSSA LSA type 7. Once these Type 7 LSA's reach the ABR connected to the backbone area 0, the LSA type 7 is converted to a LSA type 5.


*****Note keepin mind. When configuring stub areas, all the routers in that particular area also need to be configured with stub configuration or the neighbor relationship will fail, and OSPF routing will not function as the respective link-state databases will not be populated, negating the SPF process -- leading to no OSPF routes in the routing table.