My previous post about "Use a Cisco IOS Switch to Serve DHCP to Avaya Phones" was inspired by my need to quickly test connectivity with a remote site. The solution worked very well for us. Eventually we were able to deploy a server to handle all DHCP, and needed to switch over to the services on the box. My initial reaction was to simply use the "no service dhcp" command to disable DHCP, followed by adding an "ip helper-address" to the VLAN interfaces. Surprisingly the DHCP server never received any of the requests. After comparing configurations with another switch, I discovered I needed to re-run the "service dhcp" command. I had compared the "show proc | include DHCP" and noticed the DHCP processes missing on my new switch. Apparently the "ip helper-address" uses some of those DHCP services for analyzing and forwarding to the server. I ended up just removing all the "ip dhcp pool" statements to keep things clean and from causing any conflicts.

Avaya VoIP phones require a special option in a DHCP scope, so they know how to make calls. There may be times where it is desirable to have the DHCP running on a piece of networking equipment on a remote site, so that a separate server is not needed for the role. In this example there are two VLANs on each port of a Cisco switch running IOS. VLAN 52 is for user traffic, and VLAN 222 is for the VoIP traffic.

Juniper tends to have pretty good documentation in their knowledgebase, on how to configure equipment for different situations. I recently had to setup a VPN between a Juniper SSG-140 (at HQ) and a remote Cisco PIX. Going to Juniper's knowledgebase, you would most likely come across the article: http://kb.juniper.net/KB4147 . This article describes setting up a "route-based" VPN between the two devices. I believe these directions would work if you were trying to connect one subnet on each end.

I previously posted on how to "Create a VLAN Trunk between Cisco CatOS and a Foundry BigIron". During the same project I also had to create a trunk between Cisco IOS and a Foundry BigIron. Anyone who has used both CatOS and IOS know that there is a significant difference in configuring them to do the same thing. I felt it made sense to keep these posts separate, to keep people from getting confused.

In this specific situation I had to find a way to trunk multiple vlans between a Cisco 3500 IOS and a Foundry BigIron switch.

I had the need to install FreeSWAN on an old RedHat Linux 7.3 machine. While most people's initial reaction would be to upgrade the system, we all know this is not always an option.

I initially tried to do a simple "rpmbuild --rebuild..." but that did not do the trick. I would get "unresolved symbol..." errors. However, I finally found a way to get the kernel module to compile correctly.

Unfortunately Cisco and Foundry disagree on the definition of a "trunk". Awhile ago I had to find a way to trunk multiple vlans between a Cisco 5000 CatOS and a Foundry BigIron switch. I made a quick call to a Foundry Systems Engineer to find out what was needed to make this happen.

A Nokia CheckPoint Firewall was not receiving OSPF adjacency from a Cisco IOS 12.3 3640 Router. Apparently Cisco released a new feature in 12.3 (and 12.2T) that is ON by default... even though it is NEW. The feature is called, Link-Local Signalling (LLS). LLS confuses OSPF on the Nokia (even though it is RFC compliant) and is consequently rejected.

Recently I configured a router to be part of an MPLS, and it was using BGP for advertising routes with in the MPLS "cloud". By default BGP will advertise routes for interfaces directly attached to the router. Unfortunately I needed to also advertise more subnets that were “behind” the router, than those that were directly attached. I knew there had to be a simple way to add this, and quickly found that I needed a “network” statement in the BGP section of the configuration.

I needed to advertise 172.31.0.0 255.255.0.0 to the rest of the cloud.

Anti-virus and anti-spam protection at the firewall level is a growing trend, often referred to as Unified Threat Management. If you purchase one of the Juniper SSG Series firewalls, you can purchase subscriptions for “built-in” anti-virus and anti-spam UTM. Basically, you are allowed to attach these protections to an existing policy for scanning on inbound/outbound connections.
The anti-spam portion uses a Spam Block List (SBL) which is more commonly known as a Relay Block List (RBL). The SBL/RBL that Juniper offers is updated and maintained by Symantec and contains the Top 100 known spammers.
You can find a sample of the list at: http://www.juniper.net/security/spam/.

While the Top 100 known spammers is a good start, it still allows a lot of spam through which could be stopped/tagged. There is no way to add another SBL/RBL in the web GUI, but there is a hidden command in the CLI which will allow you to add other lists.

Sometimes routing can get tricky in different networking environments. It is not uncommon to be required to add routes to devices such as a F5 Big-IP.