A few days ago there was a IETF draft posted about the future of Internet routing architectures, and their recommendation (still in draft, so there is no written recommendation yet). It's a pretty good read, and very interesting to see what ideas are out there for a more secure, reliable, and scalable Internet routing architecture. The link to the draft is below:
Recommendation for a Routing Architecture
If you're interested in how I found out about this IETF draft, I subscribe to their RFC and Draft RSS feeds located here:
http://tools.ietf.org/html/
Monday, December 28, 2009
Friday, December 11, 2009
News in the World of Wireless
There have been a couple pretty big announcements in the past few days about new wireless standards currently in the works, and are steadily on track *fingers crossed*.
First off the new 802.11 standard 802.11ac is the next-gen WLAN standard that is working to achieve speeds of 1+ Gigabit/s. It's still fairly early in the standardization process, but it will be using the 5ghz spectrum (the 2.4ghz range is overly crowded now). To achieve the throughput, there are talks of using wider bands of 80Mhz (possibly 160Mhz), more modern modulation techniques, and MU-MIMO (multiple user - multiple input multiple output). The proposed date for this standard to be ratified is Dec 2012, but I wouldn't hold your breath on that (the 802.11n ridiculousness). Here's a great article on Ars Technica covering this in more detail:
The future of WiFi: gigabit speeds and beyond
The other wireless standard that is just around the bend is the WiGig standard that completed it's specification on Dec 10th. It provides 7 Gigabit/s (!) of speed using the 60Ghz spectrum, but obviously using that range the distance limitation is significant (i.e. not really to be used for WLANs). The specification says that it's good for 10 meters, but also has "support for beamforming, enabling robust communication at distances beyond 10 meters". This standard will be mainly used in the communication of video and audio between multimedia devices which require that kind of bandwidth (HD video and audio streams).
Some of the newest high-end HDTVs already have wireless communications from the main panel to a separate 'receiver' that houses all the inputs and outputs for the TV, and use the 60Ghz range used by this specification. I'm uncertain if they were early adopters of the specification, but could easily be assumed so since they are a part of the Wireless Gigabit Alliance.
Some key points listed on their website:
The WiGig version 1.0 specification includes the following key elements:
* Supports data transmission rates up to 7 Gbps – more than ten times faster than the highest 802.11n rate
* Supplements and extends the 802.11 Medium Access Control (MAC) layer and is backward compatible with the IEEE 802.11 standard
* Physical layer enables both the low power and the high performance WiGig devices, guaranteeing interoperability and communication at gigabit rates
* Protocol adaptation layers are being developed to support specific system interfaces including data buses for PC peripherals and display interfaces for HDTVs, monitors and projectors
* Support for beamforming, enabling robust communication at distances beyond 10 meters
* Widely used advanced security and power management for WiGig devices
More info at:
http://wirelessgigabitalliance.org/
First off the new 802.11 standard 802.11ac is the next-gen WLAN standard that is working to achieve speeds of 1+ Gigabit/s. It's still fairly early in the standardization process, but it will be using the 5ghz spectrum (the 2.4ghz range is overly crowded now). To achieve the throughput, there are talks of using wider bands of 80Mhz (possibly 160Mhz), more modern modulation techniques, and MU-MIMO (multiple user - multiple input multiple output). The proposed date for this standard to be ratified is Dec 2012, but I wouldn't hold your breath on that (the 802.11n ridiculousness). Here's a great article on Ars Technica covering this in more detail:
The future of WiFi: gigabit speeds and beyond
The other wireless standard that is just around the bend is the WiGig standard that completed it's specification on Dec 10th. It provides 7 Gigabit/s (!) of speed using the 60Ghz spectrum, but obviously using that range the distance limitation is significant (i.e. not really to be used for WLANs). The specification says that it's good for 10 meters, but also has "support for beamforming, enabling robust communication at distances beyond 10 meters". This standard will be mainly used in the communication of video and audio between multimedia devices which require that kind of bandwidth (HD video and audio streams).
Some of the newest high-end HDTVs already have wireless communications from the main panel to a separate 'receiver' that houses all the inputs and outputs for the TV, and use the 60Ghz range used by this specification. I'm uncertain if they were early adopters of the specification, but could easily be assumed so since they are a part of the Wireless Gigabit Alliance.
Some key points listed on their website:
The WiGig version 1.0 specification includes the following key elements:
* Supports data transmission rates up to 7 Gbps – more than ten times faster than the highest 802.11n rate
* Supplements and extends the 802.11 Medium Access Control (MAC) layer and is backward compatible with the IEEE 802.11 standard
* Physical layer enables both the low power and the high performance WiGig devices, guaranteeing interoperability and communication at gigabit rates
* Protocol adaptation layers are being developed to support specific system interfaces including data buses for PC peripherals and display interfaces for HDTVs, monitors and projectors
* Support for beamforming, enabling robust communication at distances beyond 10 meters
* Widely used advanced security and power management for WiGig devices
More info at:
http://wirelessgigabitalliance.org/
Tuesday, November 17, 2009
CCNP Certified
Well I just took the last of 4 exams for the NP today, which was the ISCW for me, and I passed 924/1000! Finally got it out of the way after a couple hiatus's the past 1.5 years (mostly work related).
Looking back, it seems like it wasn't all that difficult, and I should have pushed myself harder to get it finished sooner. But now I think I'll go for the CCIP, and I'll be sure to not give myself any slack going into it.
Once the CCIP is out of the way, it'll be time to climb the mountain that is the CCIE R&S!
Looking back, it seems like it wasn't all that difficult, and I should have pushed myself harder to get it finished sooner. But now I think I'll go for the CCIP, and I'll be sure to not give myself any slack going into it.
Once the CCIP is out of the way, it'll be time to climb the mountain that is the CCIE R&S!
Monday, November 9, 2009
WCCP and Cisco WAE Useful CLI Commands
Routers
“sh ip wccp” – Displays counters related to redirected packets
“sh ip wccp 61[62] detail” – Displays redirect packet counts, and WCCP connection uptime
“sh ip wccp 61[62] view” – Displays other known WCCP devices in the LAN
“sh ip wccp int counts”- Displays redirected packet counters per interface
“service-module Int1/0 session” – Creates console connection to NME-WAE
“no ip wccp 61[62]” – Global config to disable WCCP for services 61 and/or 62
WAE (SSH CLI)
“sh wccp gre” – Displays packet counters
“sh wccp routers” – Displays WCCP routers seen
“sh wccp services detail” – Display forwarding and return methods, and assignment method
“no wccp version 2” – Turns WCCP off to any routers peered with it
“sh auto-discovery blacklist” – Display blacklisted flows (not available in the GUI)
“sh statistics connection” – Display current TCP connections flowing through it
“sh wccp wide-area-engine” – Display WCCP connected routers
“sh run” – Display running config
“sh ver” – Display WAE software code
“sh flash” – Display WAE software code (disk and flash code)
“sh disk” – Display hard drive, RAID, file system, and encryption status
“sh license” – Display license info
“sh cms info” – Display Central Manager connection status
“wr” – Write running config to memory
“sh int gig 1/0; sh int inlinegroup 1/0” – Display physical interface stats and counters
“sh ip wccp” – Displays counters related to redirected packets
“sh ip wccp 61[62] detail” – Displays redirect packet counts, and WCCP connection uptime
“sh ip wccp 61[62] view” – Displays other known WCCP devices in the LAN
“sh ip wccp int counts”- Displays redirected packet counters per interface
“service-module Int1/0 session” – Creates console connection to NME-WAE
“no ip wccp 61[62]” – Global config to disable WCCP for services 61 and/or 62
WAE (SSH CLI)
“sh wccp gre” – Displays packet counters
“sh wccp routers” – Displays WCCP routers seen
“sh wccp services detail” – Display forwarding and return methods, and assignment method
“no wccp version 2” – Turns WCCP off to any routers peered with it
“sh auto-discovery blacklist” – Display blacklisted flows (not available in the GUI)
“sh statistics connection” – Display current TCP connections flowing through it
“sh wccp wide-area-engine” – Display WCCP connected routers
“sh run” – Display running config
“sh ver” – Display WAE software code
“sh flash” – Display WAE software code (disk and flash code)
“sh disk” – Display hard drive, RAID, file system, and encryption status
“sh license” – Display license info
“sh cms info” – Display Central Manager connection status
“wr” – Write running config to memory
“sh int gig 1/0; sh int inlinegroup 1/0” – Display physical interface stats and counters
Sunday, October 4, 2009
New Cisco IOS 15.0 Released
Seems as though Cisco quietly released the new major code version from 12.4 to 15.0.
http://www.cisco.com/en/US/docs/ios/15_0/15_0_1_m/15_0_1_m_newfeatlist.html
Time to get testing with it, and from the looks of CCO, all the code versions for the different ISRs are available for download.
Also about the different code version downloads, listed are 1900, 2900, and 3900 series routers. Looks like there's going to be more announcements coming soon...
http://www.cisco.com/en/US/docs/ios/15_0/15_0_1_m/15_0_1_m_newfeatlist.html
Time to get testing with it, and from the looks of CCO, all the code versions for the different ISRs are available for download.
Also about the different code version downloads, listed are 1900, 2900, and 3900 series routers. Looks like there's going to be more announcements coming soon...
Saturday, September 12, 2009
802.11n FINALLY Ratified
http://www.networkworld.com/news/2009/091109-80211n-approved.html?hpg1=bn
7 years later, 802.11n is officially a standard. Hopefully they didn't miss anything!
7 years later, 802.11n is officially a standard. Hopefully they didn't miss anything!
Thursday, August 20, 2009
OSPF - Router Hostname Exchange
A new RFC was just released: Dynamic Hostname Exchange Mechanism for OSPF - RFC 5642
A nice little addition that hopefully will make it into the future code versions of Cisco/etc devices. Much like the ISIS protocol that can pass along the hostname of the neighboring device, this RFC proposes the same concept for OSPF. Will be nice to not have to rely on DNS (often can be outdated, etc [at least where I work, hah]).
Now (hopefully) when you do a "sh ip ospf neigh" command (on code that actually implements this RFC), it will display the router hostname in addition to the peer IP. Could possibly eliminate the "ip ospf name-lookup" command that queries DNS for the peer IPs that match a DNS entry.
Just a little nicety...
A nice little addition that hopefully will make it into the future code versions of Cisco/etc devices. Much like the ISIS protocol that can pass along the hostname of the neighboring device, this RFC proposes the same concept for OSPF. Will be nice to not have to rely on DNS (often can be outdated, etc [at least where I work, hah]).
Now (hopefully) when you do a "sh ip ospf neigh" command (on code that actually implements this RFC), it will display the router hostname in addition to the peer IP. Could possibly eliminate the "ip ospf name-lookup" command that queries DNS for the peer IPs that match a DNS entry.
Just a little nicety...
More Space Networking
Came across another article about networking in space. This time it's NASA showing off that they have more bandwidth to the moon than I do at my house! 100Mbps speeds from a microwave amp made by L3 Comm and NASA, unbelievable! It will be able to transfer 461GB per day of images and data from the Moon back to Earth. That's a lot of Moon data!
Here's the link to the article: http://www.networkworld.com/community/node/44529.
Here's the link to the article: http://www.networkworld.com/community/node/44529.
Saturday, August 1, 2009
News
Been slacking lately with posting here, but in good reason I believe. A couple weeks ago I was promoted to the network design group, and have been tasked with researching WAN optimization products for our customer. Had to put my ISCW studying to the side for a bit while I get up to speed with WAN optimization.
Hopefully soon I'll have some good info about the intensive testing/evaluation I'm doing with Cisco WAAS and Riverbed solutions.
And a quick note about the book Deploying Cisco Wide Area Application Services is mainly good for getting a beginning to mid-level understanding of Cisco WAAS, but is lacking in the details of some important areas. It also is starting to become outdated as the screen captures are different than the latest code I've been using (4.1.3a), and never touches on designs for asymmetrical routing topologies (also a newer feature for Cisco). It does have some useful complex scenario examples though.
Hopefully soon I'll have some good info about the intensive testing/evaluation I'm doing with Cisco WAAS and Riverbed solutions.
And a quick note about the book Deploying Cisco Wide Area Application Services is mainly good for getting a beginning to mid-level understanding of Cisco WAAS, but is lacking in the details of some important areas. It also is starting to become outdated as the screen captures are different than the latest code I've been using (4.1.3a), and never touches on designs for asymmetrical routing topologies (also a newer feature for Cisco). It does have some useful complex scenario examples though.
Tuesday, July 14, 2009
The Internet... In Space!
This article is a few days old on the IEEE Spectrum webpage, but it's about NASA testing the Delay Tolerant Network protocol that has been developed for space communications and is currently being tested (link: Interplanetary Internet Tested).
Pretty fascinating about the challenges the engineers are working with when it comes to inter-networking in outer space. According to the article, eight minutes is the minimum propagation delay from Earth to Mars! That's definitely one reason to not use TCP as the transport layer protocol, hah!
Other useful links about DTN:
RFC 4838 - Delay-Tolerant Networking Architecture
Delay-Tolerant Networking Research Group (DTNRG)
NASA - Delay Tolerant Networking
Pretty fascinating about the challenges the engineers are working with when it comes to inter-networking in outer space. According to the article, eight minutes is the minimum propagation delay from Earth to Mars! That's definitely one reason to not use TCP as the transport layer protocol, hah!
Other useful links about DTN:
RFC 4838 - Delay-Tolerant Networking Architecture
Delay-Tolerant Networking Research Group (DTNRG)
NASA - Delay Tolerant Networking
Monday, June 29, 2009
Cisco Certified Architect
Cisco just announced today a new certification, the Cisco Certified Architect (CCA). Requires a valid CCIE and CCDE, and picked through an application process. Sounds pretty intense, but it should be interesting to see what kind of results the new track churns out. Some initial feedback from current CCIEs seems to be a bit melancholy since they are no longer 'at the top'.
I better get crackin at studying!
http://newsroom.cisco.com/dlls/2009/prod_062909.html
I better get crackin at studying!
http://newsroom.cisco.com/dlls/2009/prod_062909.html
Monday, June 22, 2009
Iran and the Internet
Pretty interesting read over at the WSJ about the Internet to Iran, and how they are blocking/censoring/inspecting packets: Iran's Web Spying Aided By Western Technology.
I was a bit appalled at the fact that the Siemens and Nokia joint venture that created the solution for the Iranian government to do DPI on the entire Iranian Internet connection. But as the article quotes from a spokesperson for the joint venture, they made the decision to sell the product (which was apart of a larger contract to provide a mobile network) based off of the idea that they would rather provide the ability for Iranians to communicate than not at all.
I suppose that decision is probably the correct decision (or lesser of the two wrongs). Considering that DPI isn't a perfect technology, and can often be easily circumvented, maybe they're (Siemens/Nokia) not so bad after all. Maybe knowing that fact is how they are able to sleep at night.
I was a bit appalled at the fact that the Siemens and Nokia joint venture that created the solution for the Iranian government to do DPI on the entire Iranian Internet connection. But as the article quotes from a spokesperson for the joint venture, they made the decision to sell the product (which was apart of a larger contract to provide a mobile network) based off of the idea that they would rather provide the ability for Iranians to communicate than not at all.
I suppose that decision is probably the correct decision (or lesser of the two wrongs). Considering that DPI isn't a perfect technology, and can often be easily circumvented, maybe they're (Siemens/Nokia) not so bad after all. Maybe knowing that fact is how they are able to sleep at night.
Follow-up to OSPF Boundary Tricks
I recently found a new trick that was posted in Shivlu's blog on how to eliminate OSPF External routes from entering the domain: http://shivlu.blogspot.com/2009/06/eradicate-ospf-external-routes.html.
The idea behind this method is to create a virtual loopback interface that has the same IP subnet of the customer network beyond the connected interface. You then apply the 'ip ospf network point-to-point' command to that loopback interface to avoid the IOS default of a stub host (it would only advertise the /32 address of the interface). A local static route for the customer network is then pointed out the real interface (use of route-maps is optional to block this static route if there are other statics that need to be redistributed into OSPF).
The router is then able to advertise the customer route, throughout the OSPF domain, that it knows about it 'internally'. Once the packet reaches the router, the router will use the static route to correctly route it.
Tip of the hat to Shivlu for this trick!
-Mark
The idea behind this method is to create a virtual loopback interface that has the same IP subnet of the customer network beyond the connected interface. You then apply the 'ip ospf network point-to-point' command to that loopback interface to avoid the IOS default of a stub host (it would only advertise the /32 address of the interface). A local static route for the customer network is then pointed out the real interface (use of route-maps is optional to block this static route if there are other statics that need to be redistributed into OSPF).
The router is then able to advertise the customer route, throughout the OSPF domain, that it knows about it 'internally'. Once the packet reaches the router, the router will use the static route to correctly route it.
Tip of the hat to Shivlu for this trick!
-Mark
Thursday, June 11, 2009
OSPF – Domain Boundary Tricks
There are multiple ways to limit or cut off an OSPF autonomous system from sending or receiving updates. There are a couple ways to stop updates from being sent out an interface, and there’s the concept of stubby areas that have varying levels of limiting LSAs.
Some of the reasons why a network engineer might want to enable these features are: stopping updates from being sent out an interface that connects to an external customer, reducing the processing load, reducing the memory requirements on a router, reducing bandwidth required to send updates to a remote site, and increase the stability in the OSPF process (reducing the need to run the SPF algorithm).
Database Outbound Filtering
In the example above, the “ip ospf database-filter all out” command was enabled on the core router WAN interface facing a remote site. What this command does is it stops the transmission of all OSPF LSAs going out that interface. However, it does allow OSPF hello packets to be sent and received, and therefore it can establish a neighbor adjacency. Because of the neighbor adjacency, the remote site can advertise routes to the core router, it just doesn’t receive any routes, and requires a default route for any traffic outbound from the site.
Passive-Interface
In this example, the FastEthernet0/1 interface is a connection to an external customer service and sending any OSPF packets over the interface is less than desirable. We still want to include the connected interface subnet and any subnets beyond our connected point into our OSPF domain, so other customer sites can talk to them. The “passive-interface” command stops hellos from being sent out the interface, preventing a neighbor adjacency, but still allows the connected interface route to be injected into the OSPF process. Any networks that are beyond the connected interface will require redistribution.
Stub Areas – Limiting LSAs
There are several types of stub areas that have different effects, and include: Stub Areas, Totally Stub Areas, Not So Stubby Areas (NSSA), and NSSA Totally Stub. The quick gist of their difference is which types of LSAs the ABR will send to the stub area, and then advertise a default route for all other networks.
- Stub areas will send only Intra-area and Inter-area LSAs (types 1-4) to the stub, and a default route.
- Totally stubby areas will only send Intra-area routes (types 1-2), and the default route.
- NSSAs are the same as a Stub area, but a router in the stub area is also an ASBR (routes are being redistributed into OSPF). Since Type-5 LSAs are not allowed in a Stub area, a type 7 LSA is required to send back to the core router (ABR), where it will be converted by the ABR into a type 5 LSA to advertise out.
- NSSA totally stub areas are, of course, the same as a regular NSSA, but they do not advertise any Inter-area routes into the stub (no type 3-5, only 1-2).
A network engineer might want to use one of these types of stub areas in situations similar to the first example for “Database Outbound Filtering”. Rather than cutting off all routes advertised to a remote site, having some visibility into the OSPF domain could prove to be more resilient to network outages.
Configuration of the different stub areas is fairly straight forward. Below are the commands to configure each type of stub area.
Stub Area:
Totally Stub Area:
NSSA:
NSSA Totally Stub:
The ‘area’ command that specifies the stub area must be configured on the ABR, and all routers in the stub area. The easiest way you can verify the functionality of each of the different types of stubs is with the “show ip route” command to see the “O” (intra-area), “O IA” (inter-area), “O E1” (external type-1), and “O E2” (external type-2) routes. The default route that is generated and advertised into the stub area is always listed as an OSPF inter-area route.
These are just some of the ways that I’ve come across over the past few years as a network engineer to adjust the way OSPF operates. If you know of any other ways, please post your ideas!
-Mark
Some of the reasons why a network engineer might want to enable these features are: stopping updates from being sent out an interface that connects to an external customer, reducing the processing load, reducing the memory requirements on a router, reducing bandwidth required to send updates to a remote site, and increase the stability in the OSPF process (reducing the need to run the SPF algorithm).
Database Outbound Filtering
interface Serial1/0:0.609 point-to-point description IP Services Link to RemoteA ip address 10.1.1.1 255.255.255.252 ip ospf database-filter all out router ospf 10 network 10.1.1.0 0.0.0.3 area 5 Core1#sh ip ospf int s1/0:0.609 Serial1/0:0.609 is up, line protocol is up Internet Address 10.1.1.0/30, Area 5 Process ID 10, Router ID 172.31.1.1, Network Type POINT_TO_POINT, Cost: 1 Transmit Delay is 1 sec, State POINT_TO_POINT Database-filter all out Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 oob-resync timeout 40 Hello due in 00:00:03 Supports Link-local Signaling (LLS) Cisco NSF helper support enabled IETF NSF helper support enabled Index 10/11, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 0, maximum is 0 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 172.31.1.15 Suppress hello for 0 neighbor(s)
In the example above, the “ip ospf database-filter all out” command was enabled on the core router WAN interface facing a remote site. What this command does is it stops the transmission of all OSPF LSAs going out that interface. However, it does allow OSPF hello packets to be sent and received, and therefore it can establish a neighbor adjacency. Because of the neighbor adjacency, the remote site can advertise routes to the core router, it just doesn’t receive any routes, and requires a default route for any traffic outbound from the site.
Passive-Interface
! interface FastEthernet0/1 description ***Customer 1 Service Delivery Point*** ip address 192.168.100.1 255.255.255.0 ip access-group Cust1-IN in ip access-group Cust1-OUT out rate-limit input 512000 70400 76800 conform-action set-prec-transmit 2 exceed-action set-prec-transmit 1 rate-limit output 512000 70400 76800 conform-action set-prec-transmit 2 exceed-action drop duplex auto speed auto no cdp enable router ospf 10 redistribute static subnets route-map Cust1 passive-interface FastEthernet0/1 network 192.168.100.1 0.0.0.255 area 5 ip route 192.168.101.0 255.255.255.0 192.168.100.1 tag 5000 route-map Cust1 permit 10 match tag 5000 set metric-type type-1 RemoteA#sh ip ospf int fa0/1 FastEthernet0/1 is up, line protocol is up Internet Address 192.168.100.1/24, Area 5 Process ID 10, Router ID 172.31.1.15, Network Type BROADCAST, Cost: 1 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) RemoteA.xyz.com, Interface address 172.31.2.1 No backup designated router on this network Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 oob-resync timeout 40 No Hellos (Passive interface) Supports Link-local Signaling (LLS) Cisco NSF helper support enabled IETF NSF helper support enabled Index 9/9, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 0, maximum is 0 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 0, Adjacent neighbor count is 0 Suppress hello for 0 neighbor(s) Message digest authentication enabled No key configured, using default key id 0
In this example, the FastEthernet0/1 interface is a connection to an external customer service and sending any OSPF packets over the interface is less than desirable. We still want to include the connected interface subnet and any subnets beyond our connected point into our OSPF domain, so other customer sites can talk to them. The “passive-interface” command stops hellos from being sent out the interface, preventing a neighbor adjacency, but still allows the connected interface route to be injected into the OSPF process. Any networks that are beyond the connected interface will require redistribution.
Stub Areas – Limiting LSAs
There are several types of stub areas that have different effects, and include: Stub Areas, Totally Stub Areas, Not So Stubby Areas (NSSA), and NSSA Totally Stub. The quick gist of their difference is which types of LSAs the ABR will send to the stub area, and then advertise a default route for all other networks.
- Stub areas will send only Intra-area and Inter-area LSAs (types 1-4) to the stub, and a default route.
- Totally stubby areas will only send Intra-area routes (types 1-2), and the default route.
- NSSAs are the same as a Stub area, but a router in the stub area is also an ASBR (routes are being redistributed into OSPF). Since Type-5 LSAs are not allowed in a Stub area, a type 7 LSA is required to send back to the core router (ABR), where it will be converted by the ABR into a type 5 LSA to advertise out.
- NSSA totally stub areas are, of course, the same as a regular NSSA, but they do not advertise any Inter-area routes into the stub (no type 3-5, only 1-2).
A network engineer might want to use one of these types of stub areas in situations similar to the first example for “Database Outbound Filtering”. Rather than cutting off all routes advertised to a remote site, having some visibility into the OSPF domain could prove to be more resilient to network outages.
Configuration of the different stub areas is fairly straight forward. Below are the commands to configure each type of stub area.
Stub Area:
router ospf 10 area 5 stub network 10.1.1.0 0.0.0.3 area 5
Totally Stub Area:
router ospf 10 area 5 stub no-summary network 10.1.1.0 0.0.0.3 area 5
NSSA:
router ospf 10 area 5 nssa network 10.1.1.0 0.0.0.3 area 5
NSSA Totally Stub:
router ospf 10 area 5 nssa no-summary network 10.1.1.0 0.0.0.3 area 5
The ‘area’ command that specifies the stub area must be configured on the ABR, and all routers in the stub area. The easiest way you can verify the functionality of each of the different types of stubs is with the “show ip route” command to see the “O” (intra-area), “O IA” (inter-area), “O E1” (external type-1), and “O E2” (external type-2) routes. The default route that is generated and advertised into the stub area is always listed as an OSPF inter-area route.
These are just some of the ways that I’ve come across over the past few years as a network engineer to adjust the way OSPF operates. If you know of any other ways, please post your ideas!
-Mark
Thursday, May 14, 2009
More EEM scripts...
Here are some more EEM scripts that I had saved up from a while ago, might be useful to someone else...
### This applet will configure a new 2nd Generation VWIC card (upgrading from a 1st gen VWIC) after the box is powered back on (after the tech has inserted the new card). IOS version 12.4(10.8)T or greater is needed for the 'pattern' command, in line 1.5, to work. ###
### This applet monitors the IpOutNoRoute OID, which is polled every 10 seconds. If the # of no routes is greater than 20/sec (average over two 10sec polls), it will generate a syslog message. The polled oid value is converted into an averaged rate over the last 20 seconds (average facter 2 * poll-interval 10 seconds). ###
.Aug 8 14:33:09.062: %HA_EM-2-LOG: eem-IpOutNoRoute: High IpOutNoRoutes current value is greater than 20/sec
### This applet monitors the 5min CPU Average OID , which is polled every 30 seconds. If the CPU % value is greater than 25% it will generate a syslog message. ###
### This applet monitors the ciscoMemoryPoolFree OID, which is polled every 30 seconds. If the free memory value is less than 512000 bytes it will generate a syslog message. ###
.Aug 8 14:28:57.889: %HA_EM-2-LOG: eem-LowMemory: Low Free Memory, current available memory is 499772 bytes
### This applet monitors a vlan interface to detect excessive input broadcasts. If the interface receives an average of 3000 broadcast packets per minute over a five minute period, a message will be sent to syslog. The number of broadcast packets received will be checked every 60 seconds, if the average of the 5 most recent values exceeds 3000, the event is triggered. ###
### This applet monitors for errors on an interface. If the rate of change averages to two or more over three 60 second polling cycles, then the interface is reset by doing a shut/no shut. The policy will re-arm after the rate has dropped below 1. ###
-Mark
### This applet will configure a new 2nd Generation VWIC card (upgrading from a 1st gen VWIC) after the box is powered back on (after the tech has inserted the new card). IOS version 12.4(10.8)T or greater is needed for the 'pattern' command, in line 1.5, to work. ###
event manager applet eem-2ndGen-VWIC-Install
event syslog pattern "*SYS-5-RESTART*"
action 1.0 cli command "enable"
action 1.1 cli command "config t"
action 1.2 cli command "card type t1 0 0"
action 1.3 cli command "card type t1 0 1"
action 1.4 cli command "exit"
action 1.5 cli command "copy start run" pattern "confirm"
action 1.6 cli command "running-config"
action 1.7 cli command "wr"
### This applet monitors the IpOutNoRoute OID, which is polled every 10 seconds. If the # of no routes is greater than 20/sec (average over two 10sec polls), it will generate a syslog message. The polled oid value is converted into an averaged rate over the last 20 seconds (average facter 2 * poll-interval 10 seconds). ###
event manager applet eem-IpOutNoRoute
event snmp oid 1.3.6.1.2.1.4.12 get-type next entry-op gt entry-val 20 entry-type rate average-factor 2 poll-interval 10
action 1.0 syslog priority critical msg "High IpOutNoRoutes current value is greater than 20/sec"
.Aug 8 14:33:09.062: %HA_EM-2-LOG: eem-IpOutNoRoute: High IpOutNoRoutes current value is greater than 20/sec
### This applet monitors the 5min CPU Average OID , which is polled every 30 seconds. If the CPU % value is greater than 25% it will generate a syslog message. ###
event manager applet eem-HighCPU.Aug 8 14:35:59.180: %HA_EM-2-LOG: eem-HighCPU: High CPU, current 5 min average is 28 percent
event snmp oid 1.3.6.1.4.1.9.2.1.58 get-type next entry-op gt entry-val 25 poll-interval 30
action 1.0 syslog priority critical msg "High CPU, current 5 min average is $_snmp_oid_val percent"
### This applet monitors the ciscoMemoryPoolFree OID, which is polled every 30 seconds. If the free memory value is less than 512000 bytes it will generate a syslog message. ###
event manager applet eem-LowMemory
event snmp oid 1.3.6.1.4.1.9.9.48.1.1.1.6.1 get-type exact entry-op lt entry-val 512000 poll-interval 30
action 1.0 syslog priority critical msg "Low Free Memory, current available memory is $_snmp_oid_val bytes"
.Aug 8 14:28:57.889: %HA_EM-2-LOG: eem-LowMemory: Low Free Memory, current available memory is 499772 bytes
### This applet monitors a vlan interface to detect excessive input broadcasts. If the interface receives an average of 3000 broadcast packets per minute over a five minute period, a message will be sent to syslog. The number of broadcast packets received will be checked every 60 seconds, if the average of the 5 most recent values exceeds 3000, the event is triggered. ###
event manager applet BCAST-CHECK
event interface name "Vlan100" parameter receive_broadcasts entry-val 3000 entry-op gt entry-type rate poll-interval 60 average-factor 5
action 1.0 syslog msg "BROADCAST STORM DETECTED"
### This applet monitors for errors on an interface. If the rate of change averages to two or more over three 60 second polling cycles, then the interface is reset by doing a shut/no shut. The policy will re-arm after the rate has dropped below 1. ###
event manager applet int-rate-test
event interface name FastEthernet0/24 parameter input_errors entry-op ge entry-val 2 entry-type rate exit-op lt exit-val 1 exit-type rate average-factor 3 poll-interval 60
action 1.0 syslog msg "Interface input error rate for $_interface_name is $_interface_value; resetting..."
action 2.0 cli command "enable"
action 3.0 cli command "interface $_interface_name"
action 4.0 cli command "shut"
action 5.0 cli command "no shut"
action 6.0 cli command "end
-Mark
Wednesday, May 13, 2009
EEM Scripting
This is just sort of a quicky post on EEM...
I deal a lot of multicast at work, and if you've ever tried managing a multicast network you'd understand the pain and complexity it takes to manage it. Not too long ago I came up with an EEM script to monitor a multicast stream, and to send a syslog notification if it ever drops below a certain threshold:
Can be very useful for proactive multicast monitoring if you understand the multicast application running through your network well enough to be able to set thresholds like above.
More to come with EEM....
-Mark
I deal a lot of multicast at work, and if you've ever tried managing a multicast network you'd understand the pain and complexity it takes to manage it. Not too long ago I came up with an EEM script to monitor a multicast stream, and to send a syslog notification if it ever drops below a certain threshold:
event manager applet eem-LoBW-MulticastSenderThis script monitors the multicast group X.X.X.X source Y.Y.Y.Y (with source subnet of Z.Z.Z.Z), and if the stream ever falls below 128000 bit/s (~100kbit/s), it will send a critical syslog message (you can easily substitute other actions to take instead of syslog messages here too; i.e. send an email, trap, TCL script, run CLI commands, etc).
event snmp oid 1.3.6.1.2.1.83.1.1.2.1.10.X.X.X.X.Y.Y.Y.Y.Z.Z.Z.Z get-type next entry-op lt entry-val 128000 entry-type increment poll-interval 10
action 1.0 syslog priority critical msg "Low bandwidth detected for the multicast group X.X.X.X source Y.Y.Y.Y (<100kbit/s)."
Can be very useful for proactive multicast monitoring if you understand the multicast application running through your network well enough to be able to set thresholds like above.
More to come with EEM....
-Mark
Passed the BCMSN!!
I just took the BCMSN test a couple hours ago, and passed it with ease! Pheeeww, just the ISCW left for my CCNP... here I come!!
The two things that apparently tripped me up according to my score was configuring dot1x port authentication (ok, I can understand this since it isn't apart of my everyday life), and inter-vlan routing, which I completely don't understand as there must have been something I glossed over. Oh well 90% is still pretty good in my book, on to studying for the ISCW.
Still waitin on getting a new computer (and possibly some rack equipment, we'll see though), but hopefully I can get some time to write some good articles up.
-Mark
The two things that apparently tripped me up according to my score was configuring dot1x port authentication (ok, I can understand this since it isn't apart of my everyday life), and inter-vlan routing, which I completely don't understand as there must have been something I glossed over. Oh well 90% is still pretty good in my book, on to studying for the ISCW.
Still waitin on getting a new computer (and possibly some rack equipment, we'll see though), but hopefully I can get some time to write some good articles up.
-Mark
Tuesday, April 28, 2009
Finally DOCSYS 3.0 in the US!
Very interesting news today about Cablevision announcing their new service that will support 101Mbit down/15Mbit up speeds for (a cheap by US standards) $99:
http://www.dslreports.com/shownews/cablevision-101mbps-for-9995-102133?nocomment=1
Now only if we could get up to speed (and price) with Japan and South Korea...
http://www.dslreports.com/shownews/cablevision-101mbps-for-9995-102133?nocomment=1
Now only if we could get up to speed (and price) with Japan and South Korea...
...
Don't fret, I'm still waiting on getting a new desktop computer to really get running w/ GNS3 for some good material. But as of now, my laptop that I was using died, so I'm stuck on my netbook (believe me it's no powerhouse) and work computer (don't exactly have much time to blog from work :).
Here's some topics I plan on writing about soon:
Here's some topics I plan on writing about soon:
- Multicast - Anycast RP and MSDP (maybe some about MDT in MPLS networks)
- OSPF - Performance and stability tweaks
- EEM
- Network management application reviews
- Miscellaneous IOS tricks
- etc
Sunday, April 19, 2009
The Beginning
Hi World! My name is Mark Lah, I'm a network engineer at a high-tech communications company in Melbourne, FL, and there's this thing called 'The Internet' that I kinda like.
For a while now I've been addicted to reading other networkers blogs, which I often learn new things everyday from, and I figure why not start my own professional blog that others might learn from me about technologies, scenarios, and networking in general that I've learned. I'm currently pursuing my CCNP certification (CCNA is under the belt already), I already have the BSCI and ONT exams completed, and will be taking the BCMSN here in a couple weeks. After I complete my CCNP, I plan on going after the CCDA/CCDP, and my ultimate goal in the cert world is to, of course, obtain the CCIE.
I plan on having new posts almost daily, but will realisticly be starting out much slower as I get into 'the groove' of blogging.
Thanks for stopping by, and come back soon (I should have some good reading material up soon).
-Mark
For a while now I've been addicted to reading other networkers blogs, which I often learn new things everyday from, and I figure why not start my own professional blog that others might learn from me about technologies, scenarios, and networking in general that I've learned. I'm currently pursuing my CCNP certification (CCNA is under the belt already), I already have the BSCI and ONT exams completed, and will be taking the BCMSN here in a couple weeks. After I complete my CCNP, I plan on going after the CCDA/CCDP, and my ultimate goal in the cert world is to, of course, obtain the CCIE.
I plan on having new posts almost daily, but will realisticly be starting out much slower as I get into 'the groove' of blogging.
Thanks for stopping by, and come back soon (I should have some good reading material up soon).
-Mark
Subscribe to:
Posts (Atom)