Matt vs A Cisco 837

In the summer of 2005 I was assigned the responsibility of figuring out how to connect the Salvation Army Service Extension Unit in Paso Robles to our Divisional Wide Area Network (DWAN). Having spent a little while tweaking our PIX firewall, and with a little exposure to our other networking devices, I figured it should be no big deal to get this task completed.

Enter the facts:

1. Paso Robles is in SBC territory, although not the same Lata as all our other units. This is significant in that all our SBC units talk to the central office over what is called an RLAN (private DSL network). Paso, and her sister units in the surrounding area, therefore would have to come into our network through the VPN system. Also, this meant that for the first time we would have to implement an Internet connection utilizing PPPoE, a connection protocol that uses a user name and password.

2. The networking equipment purchased for this installation was a Cisco 837 router that has a built in ADSL modem. Bla, blah, whatever. Right? No, difficult. Nowhere else in our network do we have such a device. Every other VPN location has a modem configured to bridge which handles the Internet connection. As I am not Cisco trained, and my only exposure to what works is our installation base, this device was going to be a challenge.

Two years later, having given up on using the 837 for Paso Robles (I used the DSL modem to handle the PPPoE authentication, and passed all traffic through the modem to the Cisco 1720 configured just like all our other devices), I have now been given the task of bringing my parents Quarters up onto the DWAN. In the time since the Paso install we have filled the Network Administrator position in the IT Department. My friend\co-worker Mateo has come up the ranks from Technician to take the job. As such he rightfully should be handling this aspect of the job, but having been beaten once by the 837 I want to have the last laugh. Instead of having to purchase another router, I told my boss that Id find a way to make use of the 837.

I brought the router to the Quarters, waited until the night so that I would not interfere with the normal use of the computers in the house, then proceeded to disconnect the existing Verizon provided equipment to make way for the Cisco. I should note that I first pulled up several pages of configuration examples so that I would have something to reference while I struggled to bring the house on-line again. For about three hours I wrestled with the configuration of the box. First from the command line, then from the web interface. Peculiarly, the web interface was able to detect a configuration that would work, but it always failed to write the configuration back to the device! Finally, tired and frustrated, I re-attached the Verizon equipment so I could get back on-line to do more research, and went to sleep to try again in the morning.

When I woke up I went directly to the computer and researched the new lead I had found the night before. IRB. One of the reasons I have struggled with this device is that all the configuration examples I have seen are composed of PPPoE or PPPoA settings. Verizon does not do that. Verizon uses a straight ATM bridge. Having deduced this from the web based Detection process, I managed to find some information that pointed me in the direction of the global setting “bridge irb.”With that newly discovered, I went to work manually setting up the connection. Again, I failed. Again it didnt work.

So, once again I turned to the configuration Detection process. This time I kept the command interface on screen, and did a capture to text of the outputs. When the detection completed I canceled out of it, and ran it again. This time I played the text capture to my advantage. I observed the outputs of the wizard, then as it got a connection to the ISP I ran the “show run” command. By the time the wizard completed I had a complete copy of the configuration that the wizard would not write back to the device!

Examining the configuration I found the “bridge irb” command, and the complete ATM settings that worked. So back to the command line I went, manually setting all these things into the configuration. Once that was done, I checked the interface to see if there was any connectivity with the ISP. Nothing. I saved the configuration and rebooted the device. Nothing. I must have missed something. So I pulled up the captured configuration again, and went line by line through the settings. Sure enough, down at the bottom of the configuration, buried by the line con settings were two little lines:
bridge 1 protocol ieee

bridge 1 route ip

So I slammed these two entries into the configuration and watched with glee and delight as the DHCP process happily tripped along! And with that I had the 837 talking to the Internet!

Oh wonder and rapture! Oh delight and sweet victory! How fleeting are you? I opened the browser on the computer I was using, and nothing happened. No page resolved. No ICMP echo passed. No TRACERT returned. Something just wasnt happening.

So back to the configuration I returned. Pinging Google from the router worked fine, but the client computers couldnt get through. Not sure what was causing the routing issue, I began evaluating the firewall ACL settings. I checked the NAT settings against the samples I found on-line. Nothing seemed amiss! Fighting this for several more hours I finally gave up on figuring it out on my own and called Mateo.

Mateo was my hero for the day. We talked through the configuration, tried a few things, then checked the NAT Translation table. It was empty! It seemed that we had found our issue, the NAT commands must have been mis-configured in spite of the on-line samples. We tried a static NAT entry, and wouldnt you know it, it worked! So we went through the process of reconstructing the NAT. We removed the IP NAT Inside command, removed access-list 1. Then we went to recreate the ACL... but Mateo had a tickling in the brain. He went back to his command book because something bothered him about what we were about to do. A moment later he told me what to do... instead of creating a standard numbered ACL (“access-list 1 permit ip xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx any any”) we needed to create the ACL as a named ACL! So I did. “ip access-list standard NATClients”

Once I recreated the NAT line, using the new named ACL everything worked!

So for now I have won!  With a little help from my good friend Mateo, some old bulletin board postings, and some elbow grease the house is on-line and ready to be tied into the DWAN.  Thats going to be another challenge for another day.  For now I am content that I have beaten the 837 into submission, and bent it to my will!  Hahaha!

If you would care to see the configuration, Ill post it momentarily.  And if it is helpful to someone else out there struggling with the issue of not knowing enough to do it on your own, then I am honored to have assisted.  :-)