I just finished watching Internetworkexpert Advanced video on OSPF LSA Filtering. In my last post I mentioned we can filter LSA type 3's with stub areas via the stub-no summary. The problem with this, is we will filter all LSA Type 3's.
We can also manually filter out LSA Type 3's. This is a cool option because we can be specific on what routes we want to filter to keep them from getting into the link state database, instead of filtering all Type 3's like stub area's. To do this, we create a prefix list to deny the prefix we want to filter i.e
ip prefix-list NOTME deny 150.1.5.0/24
ip prefix-list 0.0.0.0/0 le 32 (permits all other prefix, never forget the implicit deny!!!)
Then in our routing process we can call that prefix list and filter it either inbound or outbound.
** Note. You can filter based on a distribute list, however, the distribute list will not keep the prefix from going into the link-state database.
Thursday, December 31, 2009
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:
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:
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.
- 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 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.
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.
Wednesday, December 23, 2009
CCIE R&S Home Rack Completed!!
I just purchased the 9 x WIC - 1T Serial card's needed to complete my rack. My Lab will now work 100% with the Internetwork Expert Volume I, II, III, and IV workbooks. Woohoo!! No more money flying out the door anymore!!. Now the only thing flying out the door will be the many hours of studying/labbing, and probably pieces of brain matter resulting from the explosion due to trying to keep so much information inside :)
EIGRPv6 and OSPFv3
Today I started the last chapter (Chapter 20) of the CCIE R&S 4.0 certification guide. This Chapter is dedicated to a ton of information about IP Version 6 and the routing protocols that support it.
I learned that EIGRPv6 and OSPF v3(IPv6 version of ospf) have some differences if you compare them to each of these protocols IPv4 implementation. First lets start with EIGRP
With EIGRPv6 we have the following differences:
I am now going to finish reading this chapter and then watch the Advanced VOD technology videos on these topics.
I learned that EIGRPv6 and OSPF v3(IPv6 version of ospf) have some differences if you compare them to each of these protocols IPv4 implementation. First lets start with EIGRP
With EIGRPv6 we have the following differences:
- To enable EIGRPv6 you enter the command on the interface level instead of Globally as you do in with dIPv4's implementation of EIGRP i.e ipv6 eigrp 10 . This will also create the routing process on the router
- Now we have to go into the routing process and issue the "no shutdown" command to enable routing to work.
- Also, much like OSPFv3 we need to configure the ROUTER-ID in a Ipv4 32-bit address. i.e 192.168.1.1 or the routing process will not start.
- EIGRPv6 will only support filtering using a distribute-list via a prefix-list to match or deny addresses, however it does not allow you to call a route-map.
- Like EIGRPv6, OSPF is also configured on the interface level i.e ipv6 ospf 10 area 0.
- You must also configure the ROUTER-ID command using an IPv4 address. OSPFv3 can't decide the ROUTER-ID dynamically like it could with OSPFv2 . If this ROUTER-ID is not configured the routing process will not start.
- OSPFv6 will use its link-local address to establish adjacencies with other OSPFv3 speaking devices
- OSPFv6 will use the globally scoped IPv6 address when using Virtual links
- There are also some new LSA (Link state advertisements) Type 8 and Type 9
- Just like OSPFv2 you will need the neighbor statement configured when configuring OSPFv6 on a NBMA network topology.
I am now going to finish reading this chapter and then watch the Advanced VOD technology videos on these topics.
First Post CCIE Journey
I have been Networking with Cisco equipment for the last 4-5 years. I got my CCNA 3 years ago, which was quite tough for me. At that time I was not aware of Dynamips or GNS3 to help. Since I learn via hands on experience, it was tough for me to pass the CCNA exam without hands on.
When I started my CCNP studies I used dynamips to help get me through these exams and it made it alot easier. I completed my CCNP November 2007. A month later I took the CCIE R&S written and passed but I didn't have the time to completely dedicate myself to CCIE R&S lab studies. Ok, I will also add I was quite a bit intimidated with the lab and all the horror stories you hear about it.
So here i am December 2009, and I'm starting this journey all over again. I have started by reading through the CCIE 4.0 R&S written certification guide. This book seems to be alot better then the 3.0 book, a ton of information to say the least especially with the new topics they have added to the lab exam(MPLS, EIGRPv6, EEM, PfR) just to name a few.
To supplement my reading studies I have decided to go the route of buying all of the required equipment to build a home rack along with the www.internetworkexpert.com self-paced training materials. So far I have purchased the following for my rack:
My Plan to achieve the CCIE R&S milestone is as follows:
My future posts will include what I am studying that day. I will be blogging what I learned, what confuses the crap out of me, etc. Basically you will read my daily grind :)
When I started my CCNP studies I used dynamips to help get me through these exams and it made it alot easier. I completed my CCNP November 2007. A month later I took the CCIE R&S written and passed but I didn't have the time to completely dedicate myself to CCIE R&S lab studies. Ok, I will also add I was quite a bit intimidated with the lab and all the horror stories you hear about it.
So here i am December 2009, and I'm starting this journey all over again. I have started by reading through the CCIE 4.0 R&S written certification guide. This book seems to be alot better then the 3.0 book, a ton of information to say the least especially with the new topics they have added to the lab exam(MPLS, EIGRPv6, EEM, PfR) just to name a few.
To supplement my reading studies I have decided to go the route of buying all of the required equipment to build a home rack along with the www.internetworkexpert.com self-paced training materials. So far I have purchased the following for my rack:
- 3 x 2500 Series - BB1, BB2, BB3
- 3 x 3640 Routers - R1, R2, R3
- 3 x 1841 Routers - R4, R5, R6
- 2 x 3560 L3 Switches - SW1, SW2
- 2 x 3550 L3 Switches - SW3, SW4
- 1 x 4000 Router acting configured as a Frame relay Switch
- ***** I still need to buy 9 WIC 1-T Cards for my routers and my lab will be complete!
My Plan to achieve the CCIE R&S milestone is as follows:
- Finish reading CCIE 4.0 Certification Guide ( then re-read again alot of good information)
- Read TCP/IP Volumes I and II
- Watch the Adanced Technology Videos on Demand (VoD) from internetworkexpert
My future posts will include what I am studying that day. I will be blogging what I learned, what confuses the crap out of me, etc. Basically you will read my daily grind :)
Subscribe to:
Posts (Atom)