Blog: routers

 

One of our customers is using an MPLS network for their WAN connections. but they have installed backup Internet connections at their branch locations in order to maintain connectivity to the corporate office if one of the MPLS connections was to fail. See the diagram below for reference:

In order to configure the backup VPN, a VPN tunnel must be built between the main location and the branch location, in this case Router2 and Router3, respectively. Also, GRE tunnels were built between these routers so that routes could be dynamically exchanged using EIGRP, which also requires adding static routes for the GRE tunnel interfaces to route this traffic out the Internet connections instead of over the MPLS connection. All routers participate in the same EIGRP process. BGP and EIGRP are redistributed into each other on Router1. The EIGRP routes will not be preferred on the branch router (Router3) because EIGRP has a higher administrative distance (90) than BGP (20) and the BGP routes will be used. On the Internet VPN router (Router2), these routes will be preferred because EIGRP internal has a lower administrative distance (90) than external EIGRP (170). This behavior can be changed by adding the  “distance eigrp DesiredInternalAdminstrativeDistance DesiredExternalAdminitrativeDistance” (“distance eigrp 90 80” in this case) command to the EIGRP configuration.

This setup will work for failover, but will additional configuration is needed for the router to automatically failback to the MPLS connection. If the failure is at Router3, Router3 will return to using BGP routes from MPLS when the connection is restored. By default, Router1 will continue to use the routes obtained via EIGRP because the weight of these injected routes of 32768 is greater than the default weight of 0 for learned routes. This can be resolved by setting the learned routes from the BGP neighbor (ISP) to a higher weight than the injected routes. In this case, “neighbor NeighborIPAddress weight 35000” was added to the BGP configuration on Router1. These higher weight routes overwrite the injected routes. 

 The combination of changing the administrative distance in EIGRP and BGP neighbor weights allows this connection to fail to the Internet VPN and return to the MPLS connection dynamically.


 

When working with Cisco 800 model routers (and probably any Cisco Integrated Services Router) you might run into an issue that the VLAN which is assigned to the LAN ethernet ports is in an “up/down” state.  This is because an SVI must meet all of the following conditions to transition to the full "up/up" state:

  • The VLAN must exist and be active in the VLAN database.
  • At least one switched port in the VLAN (access or trunk) must be up.
  • That port must be in the STP forwarding state.

Sometimes it is necessary to have that VLAN interface up even if there are no devices or ports using that VLAN.  [more]The most recent case that I experienced this need was when I was trying to transfer IOS images remotely across a VPN connection.  Because the transfer was traversing across the VPN I had to source the file transfer from the internal VLAN interface.   There weren’t any PC’s connected to the router so the VLAN interface was in an “up/down” state.  To resolve this issue, I could have either connected a PC or a loopback into the router or simply forced the VLAN into an “up/up” state.  Issuing the “no autostate” command on the VLAN interface will bring the interface up.  Basically, the command just tells the VLAN interface to ignore the above mentioned prerequisites.  Note: This command is only available in certain IOS images.


 

About 2 weeks ago a new botnet worm called "psyb0t" was discovered according to DroneBL blog post (http://www.dronebl.org/blog/8).  This worm appears to be the first botnet worm to specifically target routers and DSL modems.  It is believed the worm has been active since at least January, and it is estimated that more than 100,000 hosts have been infected so far.  The worm was first discovered by DroneBL as part of an investigation into the DDoS attacks against DroneBL's infrastructure.  A few of the malicious things the worm is designed to do include; harvest account information (usernames & passwords) through deep packet inspection, attempt to brute-force accounts, and can scan for exploitable phpMyAdmin and MySQL servers.