The Silo Chronicles
The not so exciting adventures of a Network Engineer

It’s a wrap! Another year of Networkers is done. The party was awesome this year. The Blue Man Group was incredibly interactive and fun. They had half of Universal Studio opened up with an incredible amount of food and beer. I wrapped the evening up with the Bare Naked Ladies concert. All in all it was my favorite event out of the three Networkers I have been too.

The Ben Stein keynote was very good. He brought up so many great points about the economy and direction of our country. My classes today were pretty good. I took a SIP class yesterday and a CUBE class this morning. It sounds like this will be very relevant in the future. The rest of my classes were pretty good as well. Definitely looking forward to next year.

So much for my daily updates! I ended up falling asleep before I got around to posting last night. Yesterday I had a Techtorial on IPSec & SSP VPNs. Like most techtorials I learned a great deal and my head subsequently hurt. I could go into great details about what was covered but I can sum it up by saying if it deals with VPNs they covered it. Everything from GRE to EasyVPN to GetVPN. After my session I swung by the Welcome party at the World of Solutions and they had tons of beer and food like normal. They seemed to have more swag floating around this year then in past but it feels a little smaller but maybe it is just me.

Today was my first day of breakout sessions. This is my third year of Networkers and I am starting to find that I am under estimating my knowledge of various subjects. It’s amazing how much you can pick up on a daily basis by simply deploying various technologies. Unfortunately I am going to have to start picking my sessions a bit better. Today I had two sessions that were good but nothing new and I felt like I wasted two great opportunities. My day was saved by my third sessions “Deploying DMVPNs”. I haven’t had a chance to deploy any DMVPNs yet and this is now my third session that covered the topic but this one was very insightful on plans to start rolling it out. Very good stuff. I swung by the World of Solutions for my fill of food and beer and called it a night. All in all a decent day but I am hoping tomorrow is better. Tomorrow night is the Customer Appreciation Event so I probably won’t be updating my blog until Thursday.

My wife loves to make fun of the fact that my favorite week of the year is Networkers and not any of our vacations. After my first day I can unfortunately confirm this is yet again true. This year’s bag is better than last year but not as best as the 2006 bag. It is bigger than last year but not big enough to use on a daily basis. They also introduced two new things this year. The first is a refillable water bottle. I had read about this on their website and was surprised to find it wasn’t a generic plastic water bottle but a aluminum bottle. It is a really nice bottle but leaves a nasty taste in the water but I washed it out so hopefully it will be better tomorrow. The second is a 2gb USB stick with all of the session PDFs. It is branded for the event and looks decent the only thing I want to know is if it is readable in the Cisco equipment.

Today was my Catalyst 6500 Technical Deep Dive. I have always considered my knowledge of the 6500 to be fuzzy knowledge and this class did an incredible job of explaining much of the inner workings. They went into painful detail covering how packets flow thru the switch and supervisor cards which was great. They also touched on all sorts of other aspects including the new Sup32 PISA, VSS, QoS, FWSM and ACE.

After this week I am going to go back through my notes and write a few good blog posts about the various tidbits of quick knowledge I gleaned from the week. It is now time to let my brain relax before day 2.

I came across some review questions regarding T1 alarms and I thought this would be a good topic for the day. Understanding T1 alarms is important since without understanding what the alarm means it is very difficult to troubleshoot. There are two categories of alarms, receive and transmit. Inside of these categories there are colors. Each color corresponds with a different type of alarm.

First things first. To display the status of a T1 issue the following command:

Receive Alarm Indication Signal (Blue)

A receive alarm indication signal (AIS) means there is an alarm occurring on the line upstream from the equipment that is connected to the port. The AIS failure is declared when an AIS defect is detected at the input and still exists after the Loss Of Frame failure is declared. The AIS failure is cleared when the Loss Of Frame failure is cleared.

Receive Remote Alarm Indication (Yellow)

A receive remote alarm indication (RAI) means the far end equipment has a problem with the signal it is receiving from the upstream equipment (aka your equipment). When using superframe the far end alarm failure is decalred when bit 6 of all of the channels has been zero for at least 335 ms. The failure is cleared when bit 6 of at least one channel is not zero for a period usually less than one second and always less than five seconds. The Far End Alarm failure is not declared for SF links when a Loss of Signal is detected. For extended superframe links, the Far End Alarm failure is declared if the Yellow alarm signal pattern occurs in at least seven out of ten contiguous 16-bit pattern intervals. The failure is cleared if the Yellow alarm signal pattern does not occur in ten contiguous 16-bit signal pattern intervals.

Transmit Sending Remote Alarm (Red)

A transmit sending remote alarm is declared when the channel service unit (CSU) cannot synchronize with the framing pattern on the T1 line.

Transmit Remote Alarm Indication (Yellow)

A transmit remote alarm indication (RAI) at a DS1 interface means that the interface has a problem with the signal it is receiving from the far end equipment.

Transmit Alarm Indication Signal (Blue)

This is a very unusual alarm. As long as framing is correct this most likely means the controller is bad. You can confirm this by performing a hardware loop test.

Conclusion

As many engineers will tell you 9 times out of 10 when you get an alarm it is a service provider issue. Either way it is always handy to understand what you are seeing because most likely the person you have to call to report it won’t.

For more information visit:
http://www.cisco.com/en/US/tech/tk713/tk628/technologies_tech_note09186a00801069ff.shtml

The time of year has finally arrived again. Networkers has returned and I will be busy soaking up all things networking next week. I have signed up for two Techtorials and jammed my schedule as full as it can possibly be. In case you are interested below is a list of the sessions I will be taking.

TECRST-2002 – Cisco Catalyst 6500 Series Technical Deep Dive
TECSEC-2040 – IPSec and SSL VPNs
BRKAGG-3013 – Wireless LAN Radio Spectrum Management Best PracticeBRKARC-2002 – Troubleshooting Cisco IOS Router Operation
BRKRST-3141 – Troubleshooting Cisco Catalyst 3750, 3550 and 2900 Series Switches
BRKRST-3143 – Troubleshooting Cisco Catalyst 6500 Series Switches
BRKSEC-2012 – Deploying Dynamic Multipoint VPNs
BRKSEC-3009 – Operational Firewall and IPS Management Using Cisco Security Manager and Cisco Security MARS
BRKSEC-3020 – Troubleshooting Firewalls
BRKSEC-3030 – Troubleshooting Intrusion Detection Systems
BRKVVT-2006 – SIP Trunks for PSTN Access
BRKVVT-2022 – Cisco Unified Communications Manager Media and Resource Management

As you can notice I signed up for a bunch of the troubleshooting breakout sessions. In the previous years I have taken a large concept/theory sessions I was planning on looking into in the future. This year I decided I want it to be a bit more practical and focus on sharping my overall troubleshooting skills. Needless to say I am pretty excited. If you are going to be out there drop me a line and maybe we can meet up.

I was reviewing some material on dial-peer configurations and found a section that I found rather interesting. While I have had extensive experience with integrating with PSTN my experience with integrating with PBX systems has been limited. As such the topic for today is special-purpose connections. There are four types of speciail-purpose connections and they are as follows:

Private Line, Automatic Ringdown (PLAR)

This is an autodialing mechanism that permanently associates a voice port with a static far-end destination. This command is very commonly found on FXO ports. When a call comes into a FXO voice port the connection plar statement tells the port where to send the call. For example:

This tells the router to send the call to 2000. A search of dial-peers is then started for the matching 2000.

PLAR-OPX (Off Premises eXtension)

This is a PBX extension that is located at a seperate business site and operates as though it is directly connected to the PBX. A common use for this is telecommuters. It allows telecommuters to utilize the same four-digit system at home. The difference between PLAR and PLAR-OPX is that with PLAR as soon as ringing current is applied CallManager considered the call complete. This becomes a problem because if the remote end does not answer the call and you wish the call to be sent to a central voicemail system. When you use the PLAR-OPX the call is not considered completed until the call is actually answered. For example:

Again the configuration is nearly the same the only difference is when the router considers the call answered.

Trunk Connection

This emulates a permanent connection between two systems. These systems could be two PBXs, a PBX and local extension or some combination of telephony interfaces that have their signaling passed transparently through the data network. The conneciton remains permanent in the absence of active calls and is established immediately after configuration. For example:

A common implementation of this would be TDM cross connect using E&M Wink-Start. It should be noted that one the following voice-port combinations must be used:

• E&M to E&M
• FXS to FXO
• FXS to FXS (with no signaling)

You must also meet the following conditions:

• You can not perform number expansion on the destination-pattern telephone numbers.
• You must configure both ends for the trunk connection.

Tie-Line

A tie-line connection is a temporary trunk to a PBX. This follows the same principles as a trunk except the connection is built on demand and is only active when needed. For example:

Router A

Router B

There you have it. The four basic special-purpose connections. If you have anything to add please leave a comment.

For some reason I have a had time remembering the order of IP Precedence. This is primarily because I don’t have a mnemonic for it. Well that changed tonight. While reviewing various materials for my upcoming CVoice exam I decided to come up with one. With the help of a mnemonic generator and a combination of several results I have come up with the following.

These types of memory tables I find invaluable. While IP Precedence is now clearly second place to DSCP it still is useful and you never know which this simple amount of information might come in handy.

I first deployed a series of ASA5505s running 7.2 about six months ago and one of the things I noticed is that I was getting what seemed to be pre-mature NAT terminations. I would see PC A contact Server B, Server B send results back when all the sudden I would get a message about no translate for the PC A to Server B and then ACL denies for Server B to PC A on the former NAT port. I opened a TAC case at the time and was told this was working as expected.

Flash forward six months and many ASAs later including an upgrade to 8.0(3) and the problem still remains. This became more than just a nuisance with a recent deployment of CS-MARS. Suddenly we were getting inundated with incidents relating to these issues. I again went to TAC and they told me is was a non-issue. After pressing them some more and lots of packet capturing and testing we were able to narrow it down. The issue was relating to the following configurations:

As soon as I removed these lines the issue went away. The only thing left to dispute now is if this is a bug or working as intended. Obviously Cisco quickly says it is working as intended, which I find hard to believe. Either way if you run into this issue and want to correct it look for your threat-detection configuration and remove it. For a complete explanation of what these commands do visit:

http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/t.html#wp1462189