• Skip to main content
  • Skip to footer

NetworkJutsu

Networking & Security Services | San Francisco Bay Area

  • Blog
  • Services
  • Testimonials
  • About
    • About Us
    • Terms of Use
    • Privacy Policy
  • Contact Us

Router

Router versus Firewall: What are the differences?

06/22/2020 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email
router versus firewall

There seems to be some confusion about the differences between the router and firewall. One of the contributing factors to this is that device manufacturers tend to combine the functionalities into one device. Traditionally, these devices are specialized hardware that does a specific job well.

Both of these devices have advantages and disadvantages over the other, unique features, and different purposes. In this article, we will define what they are, identify their primary use in your network, and explain why you may need both.

What is a router?

A router is a device that quickly forwards data from one network to another. For example, for your devices to communicate to the Internet, you need a networking device to transmit the traffic from your home to the Internet Service Provider (ISP). Typically, this device is a router that either you purchased or provided by your ISP.

The type of router found in most homes and some small businesses is called a wireless router. The wireless router combines the functionalities of multiple devices: wireless access point, switch, and a router.

Furthermore, a lot of routers in the market provide some level of network security by including features like Network Address Port Translation (NAPT), Stateful Packet Inspection (SPI), etc.

What does a router do?

The principal function of a router is to route network traffic between networks. The job of a router is similar to the role of the United States Postal Service (USPS). The router tries its best to forward the data between the sender and the receiver in different networks.

Since the majority of routers in a lot of small businesses are wireless routers, they also allow the connection of wired and wireless devices such as computers, printers, mobile devices, etc.

What is a firewall?

A network-based firewall is a device that provides security by monitoring incoming and outgoing traffic and makes a decision whether to allow or deny specific traffic based on the rule sets.

For many years, the firewall has been an integral part of any successful security program. It serves as the first line of defense in network security.

Today’s modern operating systems, such as Windows and macOS, include a software firewall that provides added network protection. A software host-based firewall functions similarly to a traditional network-based firewall.

Nowadays, firewall manufacturers add extra features like anti-malware, Intrusion Prevention System (IPS), application awareness, URL filtering, etc. referred to as a next-generation firewall (NGFW). An NGFW offers far improved security than a router or a traditional firewall.

What does a firewall do?

The principal function of a firewall is to provide network protection by blocking unwanted traffic. A job of a firewall is similar to the role of the Transportation Security Administration (TSA). The firewall inspects network traffic to make sure everything looks good before it is allowed to pass through.

Some firewalls designed for small businesses or branch offices also combine functionalities of wireless routers, allowing both wired and wireless network connectivity.

Which one should you buy?

Unfortunately, the answer to this question is it depends. Determining the right device for your business requires an understanding of the goals and requirements.

For a small coffee shop, a wireless router from your favorite retailer may be sufficient. For some small and medium-sized businesses (SMB), they may opt to purchase NGFW for better security.

In some scenarios, you might need to purchase both a router and a firewall. For example, if a branch office has the following requirements: WAN connectivity options (both wired and wireless), VoIP, switching, NGFW, and computing. Then, buying a router that can do the majority of these requirements and a separate NGFW could be a suitable solution.

There are some instances where you don’t want to, by default, restrict network traffic. For example, in higher education space, the researchers may expect no restrictions and a fast network to transfer data between each other.

Summary

Both devices can provide a level of network security. However, NGFW gives a higher level of protection compared to a router with some firewalling features.

Choosing between a router and a firewall will vary from one company to another. The key to determining the proper device is by gathering the requirements, goals, and business and technical constraints.

If security is paramount to your company, then purchasing a next-generation firewall with a subscription to the advanced features is the right way to go.

Still unsure on what to get?

Let us answer your questions by contacting us. We’ll help you with hardware selection, design, configuration, and implementation.

LET’S TALK

NetworkJutsu provides networking and network security consulting services for startups, a more established small and medium-sized business (SMB), or large business throughout the San Francisco Bay Area.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

RIP Authentication

06/15/2014 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

I was watching INE videos about RIP and when I reached the RIP Authentication video, I apparently forgot about the key number must match requirement when using MD5. To be honest, it wasn’t the only one I forgot about RIP. Heck, I usually forget what I read last night! It’s a constant struggle that I deal with every single day. I think I need a flash drive or the “Limitless” pill so that I can remember everything I read, but I digress.

Clear Text Method

There are two methods that can be used when enabling RIP Authentication: clear text and MD5. For security purposes, cleartext should not be used in production. This method has two requirements: key string and authentication must match for it to work. That said, even if the key number doesn’t match the routers will still exchange routes just fine. For completeness sake, the example is shown below.

Router 1 configuration and verification:

R1#sh run | se key         
key chain rip
 key 1
   key-string cisco
 ip rip authentication key-chain rip
R1#sh ip route rip | se sub
      22.0.0.0/24 is subnetted, 1 subnets
R        22.22.22.0 [120/1] via 1.1.1.2, 00:00:04, GigabitEthernet1

Router 2 configuration and verification:

R2#sh run | se key         
key chain rip
 key 2
   key-string cisco
 ip rip authentication key-chain rip
R2#sh ip route rip | se sub
      11.0.0.0/24 is subnetted, 1 subnets
R        11.11.11.0 [120/1] via 1.1.1.1, 00:00:19, GigabitEthernet1

MD5 Authentication

This method is the recommended mode in-production for obvious reasons. This method has three requirements: key number, key string, and authentication must match. We all know what it looks like when it works, but what happens when we actually introduce a fault in the configuration? In theory, it shouldn’t work, right? Well, let’s take a look.

Router 1 and Router 2 are configured with two different key string:

R1#sh run | se key         
key chain rip
 key 1
   key-string cisco
 ip rip authentication key-chain rip
R1#sh ip route rip | se sub
R1#
R1#debug ip rip events
*Jun 15 22:59:02.665: RIP: ignored v2 packet from 1.1.1.2 (invalid authentication)
R2#sh run | se key
key chain rip
 key 1
   key-string systems
 ip rip authentication key-chain rip
R2#sh ip route rip | se sub
R2#
R2#debug ip rip event
*Jun 15 22:51:29.159: RIP: ignored v2 packet from 1.1.1.1 (invalid authentication)

As expected, both routers ignored the update and didn’t process the update.

Router 1 and Router 2 are configured with two different authentication mode:

R1#sh run | se mode md5|key
key chain rip
 key 1
   key-string cisco
 ip rip authentication mode md5
 ip rip authentication key-chain rip
R1#sh ip route rip | se sub
R1#
R1#debug ip rip event
RIP event debugging is on
*Jun 15 23:08:45.068: RIP: ignored v2 packet from 1.1.1.2 (invalid authentication)
R2#sh run | se mode md5|key
key chain rip
 key 1
   key-string cisco
 ip rip authentication key-chain rip
R2#sh ip route rip | se sub
R2#debug ip rip event
RIP event debugging is on
*Jun 15 23:08:40.623: RIP: ignored v2 packet from 1.1.1.1 (invalid authentication)

Again, it’s expected to not work.

Router 1 and Router 2 are configured with two different key number:

R1#sh run | se key|mode md5
key chain rip
 key 1
   key-string cisco
 ip rip authentication mode md5
 ip rip authentication key-chain rip
R1#sh ip route rip | se sub
R1#debug ip rip event
RIP event debugging is on
*Jun 15 23:20:33.452: RIP: ignored v2 packet from 1.1.1.2 (invalid authentication)

R2#sh run | se key|mode md5
key chain rip
 key 2
   key-string cisco
 ip rip authentication mode md5
 ip rip authentication key-chain rip
R2#sh ip route rip | se sub
      11.0.0.0/24 is subnetted, 1 subnets
R        11.11.11.0 [120/1] via 1.1.1.1, 00:00:18, GigabitEthernet1
R2#debug ip rip eve
RIP event debugging is on
*Jun 15 23:23:15.984: RIP: received v2 update from 1.1.1.1 on GigabitEthernet1
*Jun 15 23:23:15.984: RIP: Update contains 1 routes

Now, this is interesting output. Why did R2 process the update of R1 and installed its routing table and R1 ignored the update from R2? The only thing that makes sense is the feature of RIP (and most likely EIGRP too) that it can store multiple keys in its database to change up so that it can mitigate the keys being compromised. RFC 2082 doesn’t talk about it but it does talk about multiple keys and rollover so I think it’s related to that. I haven’t seen a Cisco doc about this specifically so please feel free to drop me a comment pointing to one that explains this behavior.

For experimentation’s sake, I decided to add another key number in R1 that matches R2’s configuration. R1 did process the RIP updates and installed it in the routing table, as one would expect since all three requirements were met.

R1#sh run | se key|md5
key chain rip
 key 1
   key-string cisco
 key 2
   key-string cisco
 ip rip authentication mode md5
 ip rip authentication key-chain rip
R1#sh ip route rip | se sub
      22.0.0.0/24 is subnetted, 1 subnets
R        22.22.22.0 [120/1] via 1.1.1.2, 00:00:17, GigabitEthernet1
*Jun 15 23:33:49.378: RIP: received v2 update from 1.1.1.2 on GigabitEthernet1
*Jun 15 23:33:49.378: RIP: Update contains 1 routes

Thoughts

I wish Cisco’s documentation and/or Cisco Press’ authors covered this but I haven’t seen one that did. Even Cisco’s configuration guide, and configuration examples didn’t explain much about the keys. Perhaps, they feel like RIP shouldn’t be covered as detailed as the other routing protocols since it’s rarely used in production. What are your thoughts?

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Proxy ARP

02/25/2012 By Andrew Roderos 2 Comments

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Proxy ARP (Address Resolution Protocol) is a technique in which a device, usually a router, answers ARP queries intended for another device. Cisco routers and Catalyst multilayer switches have this protocol turned on by default. This allows a misconfigured device to reach other subnet without setting a default gateway. This also pose a security problem since it will allow an attacker to issue multiple ARP requests and use up the router/switch’s resources when it tries to respond to all ARP requests in a DoS (denial of service) attack.

An example of how proxy ARP works is shown below. In this example, there are four devices – two of them are acting as routers and the other two are acting as a regular PC. The R1’s IP configuration was configured correctly, while the R4’s IP configuration was configured with incorrect subnet mask and no default gateway.

R1’s IP configuration and routing table:

R1#sh run int f0/0
Building configuration...
Current configuration : 97 bytes
!
interface FastEthernet0/0
 ip address 172.17.100.1 255.255.255.0
 duplex auto
 speed auto
end
R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route
Gateway of last resort is 172.17.100.254 to network 0.0.0.0
     172.17.0.0/24 is subnetted, 1 subnets
C       172.17.100.0 is directly connected, FastEthernet0/0
S*   0.0.0.0/0 [1/0] via 172.17.100.254

R4’s IP configuration and routing table:

R4#sh run int f0/0
Building configuration...
Current configuration : 92 bytes
!
interface FastEthernet0/0
 ip address 172.17.99.1 255.0.0.0
 duplex auto
 speed auto
end
R4#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
C    172.0.0.0/8 is directly connected, FastEthernet0/0

Now, let’s try to ping R1 from R4. This should be successful since proxy ARP is enabled by default on Cisco routers.

R3’s show ip interface f0/0 output:

R3#sh ip int f0/0
FastEthernet0/0 is up, line protocol is up
  Internet address is 172.17.99.254/24
  Broadcast address is 255.255.255.255
  Address determined by setup command
  MTU is 1500 bytes
  Helper address is not set
  Directed broadcast forwarding is disabled
  Multicast reserved groups joined: 224.0.0.10
  Outgoing access list is not set
  Inbound  access list is not set
  Proxy ARP is enabled
  Local Proxy ARP is disabled
! Omitted for brevity

R4’s ping output:

R4#ping 172.17.100.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.17.100.1, timeout is 2 seconds:
..!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 40/52/60 ms

My guess on the two packets that failed were because it took a while before the router steps in to be the proxy. Once R4 has the MAC address of R1 in the ARP table any succeeding communication between them will be successful.

Now, let’s disable proxy ARP on R3 and make sure R4’s ARP table does not have R1’s IP address.

R3(config)#int f0/0
R3(config-if)#no ip proxy-arp
R3#sh ip int f0/0
FastEthernet0/0 is up, line protocol is up
  Internet address is 172.17.99.254/24
  Broadcast address is 255.255.255.255
  Address determined by setup command
  MTU is 1500 bytes
  Helper address is not set
  Directed broadcast forwarding is disabled
  Multicast reserved groups joined: 224.0.0.10
  Outgoing access list is not set
  Inbound  access list is not set
  Proxy ARP is disabled
  Local Proxy ARP is disabled
! Omitted for brevity
R4#sho ip arp f0/0
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  172.17.99.254          17   c002.1704.0000  ARPA   FastEthernet0/0
Internet  172.17.100.1            8   c002.1704.0000  ARPA   FastEthernet0/0
Internet  172.17.99.1             -   c003.1704.0000  ARPA   FastEthernet0/0
R4#clear arp int f0/0
R4#sho ip arp f0/0
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  172.17.99.254           0   c002.1704.0000  ARPA   FastEthernet0/0
Internet  172.17.99.1             -   c003.1704.0000  ARPA   FastEthernet0/0

Now R4 does not have the 172.17.100.1 listed in the ARP table let’s try to ping R1.

R4#ping 172.17.100.1 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 172.17.100.1, timeout is 2 seconds:
..........
Success rate is 0 percent (0/10)

As shown above, R4 is now unable to communicate with R1 when proxy ARP is disabled. This should definitely be disabled when it is not needed to harden your Cisco network devices. For more tips to harden your Cisco network devices, please visit here. I will keep adding to this list as time allows.

I hope this has been helpful and thank you for reading!

References

Cisco Proxy ARP
Basic Cisco IOS Software and Catalyst 3550 Series Security

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Two Port T1/E1 Voice/WAN Interface Card

02/16/2012 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

I like using VWIC-2MFT-T1 card since it gives me the ability to save WIC slots on smaller routers, like Cisco 1841. If you’re also in a budget, it is quite useful to combine voice and data T1 with this card. Though, you may want to separate them so it won’t be a single point of failure.

The first time I’ve installed this on a 2821 router, I didn’t see any serial interfaces at all in the show ip int br output, as shown below. Second thing I checked was, if the card was being recognized using show diag and show ver, as shown below.

Router#show ip int br
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         unassigned      YES unset  administratively down down
GigabitEthernet0/1         unassigned      YES unset  administratively down down
Router#show ver | i T1
2 Channelized (E1 or T1)/PRI ports
Router#show diag | i VWIC
        VWIC2-2MFT-T1/E1 - 2-Port RJ-48 Multiflex Trunk - T1/E1
        Product (FRU) Number     : VWIC2-2MFT-T1/E1

Looking at the output, the card was being recognized so I asked myself why was not seeing the serial interfaces. Upon reading Cisco’s documentation, I discovered that I needed to issue commands to enable them and show up as serial interfaces. Though, this may vary router/IOS to router/IOS. When I installed it on a Cisco 1841, I didn’t have to use card type command. In this particular scenario, I am using a Cisco 2901 router with IOS version 15. Normally, you can determine this by doing a show run to see if card type command is needed, as shown below.

Router#sh run
Building configuration...
Current configuration : 880 bytes
!
! No configuration change since last restart
!
version 15.0
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
! card type command needed for slot/vwic-slot 0/0
! card type command needed for slot/vwic-slot 0/1
! card type command needed for slot/vwic-slot 0/2
!
no aaa new-model
! Output omitted for brevity

As you can see from above, there’s a message that you need to issue the card type command. The commands you need to enable the VWIC-2MFT-T1 or VWIC2-2MFT-T1 are shown below.

Router(config)#card type t1 0 0
Router(config)#controller t1 0/0/0:0
Router(config-controller)#framing esf
Router(config-controller)#linecode b8zs
Router(config-controller)#channel-group 1 timeslots 1-24
Router(config-controller)#
Feb 17 01:07:29.255: %LINK-3-UPDOWN: Interface Serial0/0/0:1, changed state to down
Feb 17 01:07:30.255: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0:1, changed state to down
Router(config-controller)#controller t1 0/0/0:1
Router(config-controller)#channel-group 1 timeslots 1-24
Router(config-controller)#
Feb 17 01:08:01.031: %LINK-3-UPDOWN: Interface Serial0/0/1:1, changed state to down
Feb 17 01:08:02.031: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1:1, changed state to down
Router(config-controller)#do sh ip int br
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         unassigned      YES unset  administratively down down
GigabitEthernet0/1         unassigned      YES unset  administratively down down
Serial0/0/0:1              unassigned      YES unset  down                  down
Serial0/0/1:1              unassigned      YES unset  down                  down

Again, this may not be a good idea if you’re concern about single point of failure. However, I find these cards pretty reliable and I have not seen them fail. They’re best if you’re concern with WIC/VWIC slot density, especially when you start using more than two bonded T1s.

I hope this has been helpful and thank you for reading!

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

GRE Tunnel Recursive Routing

01/15/2012 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Ever seen this error message %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing? The most common reason for this error is that the router is trying to route to the tunnel destination address using the tunnel interface itself. This error message will keep flooding your router until someone fixes the misconfiguration of the router. This will also mean that your tunnel interface will keep flapping until fixed.

Let’s take a look at a scenario in which recursive routing is being experienced. In this particular environment, there are several remote branches that will need to establish a GRE tunnel to the headend. For simplicity, the diagram only shows two remote branches and the configuration only shows the headend and a remote branch. Please ignore the IP addressing as I just picked random numbers. The 172.18.0.0/16 address, however, has been assigned to be the serial interfaces of the remote branch routers.

Here are the configuration of the enterprise routers:

GRE-HEADEND

interface Loopback0
 ip address 172.17.254.254 255.255.255.255
!
interface Loopback1
 ip address 172.17.1.254 255.255.255.0
!
interface Tunnel1
 ip unnumbered Loopback0
 tunnel source Serial0/0
 tunnel destination 172.18.1.254 
!
interface Serial0/0
 ip address 172.19.0.254 255.255.255.0 
!
router eigrp 1
 network 172.0.0.0 0.255.255.255
 no auto-summary 
! 
ip route 172.18.0.0 255.255.0.0 Serial0/0
!

REMOTE-R1

interface Loopback0
 ip address 172.17.2.254 255.255.255.255
!
interface Tunnel1
 ip unnumbered Loopback0
 tunnel source Serial0/0
 tunnel destination 172.19.0.254
!
interface FastEthernet0/0
 ip address 172.24.1.254 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0
 ip address 172.18.1.254 255.255.255.0
!
router eigrp 1
 network 172.0.0.0 0.255.255.255
 no auto-summary
!
ip route 172.19.0.0 255.255.255.0 Serial0/0
!

Once the routers able to reach their tunnel destination IP address and when the tunnel interfaces comes up/up on both routers, then they’ve established the GRE tunnel. However, once they start exchanging EIGRP the tunnel will go down due to recursive routing. The router will automatically reestablish GRE tunnel and establish EIGRP neighborship but will eventually go down again, as shown below. This is a cycle and will never be fixed unless a human intervention.

GRE-HEADEND#
*Mar  1 03:08:46.087: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
*Mar  1 03:08:50.435: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.17.2.254 (Tunnel1) is up: new adjacency
GRE-HEADEND#show ip eigrp neigh
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   172.17.2.254            Tu1               14 00:00:05   32  5000  2  40
GRE-HEADEND#
*Mar  1 03:08:55.087: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing
*Mar  1 03:08:56.087: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Mar  1 03:08:56.127: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.17.2.254 (Tunnel1) is down: interface down

So what’s the problem here? Well, it is quite simple really. The GRE-HEADEND router has a static route that is shorter prefix to reach the tunnel destination address of the remote routers – ip route 172.18.0.0 255.255.0.0 s0/0. Since this is a shorter prefix, the GRE-HEADEND router will eventually learn a better route via EIGRP and will try to use that to reach the tunnel destination address. Unfortunately, that’s not going to work since the router learned it via EIGRP which has a next hop interface of Tunnel1, as shown below.

GRE-HEADEND#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
     172.17.0.0/16 is variably subnetted, 3 subnets, 2 masks
D       172.17.2.254/32 [90/297372416] via 172.17.2.254, 00:00:01, Tunnel1
C       172.17.1.0/24 is directly connected, Loopback1
C       172.17.254.254/32 is directly connected, Loopback0
     172.19.0.0/24 is subnetted, 1 subnets
C       172.19.0.0 is directly connected, Serial0/0
     172.18.0.0/16 is variably subnetted, 2 subnets, 2 masks
S       172.18.0.0/16 is directly connected, Serial0/0
D       172.18.1.0/24 [90/297756416] via 172.17.2.254, 00:00:03, Tunnel1
     172.24.0.0/24 is subnetted, 1 subnets
D       172.24.1.0 [90/297270016] via 172.17.2.254, 00:00:03, Tunnel1

The solution for this recursive routing issue is to remove the static route with a shorter prefix and add a static route with a longer prefix, so the router won’t use the route learned via the IGP, in this case EIGRP. Remember the rules of how the router places routes in the routing table: the more specific route gets placed, if it’s a tie then the route with the best AD (Administrative Distance) value, and if the AD value is a tie then the route with the best metric will be placed.

GRE-HEADEND(config)#ip route 172.18.1.0 255.255.255.0 s0/0
GRE-HEADEND#
*Mar  1 03:19:17.611: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
GRE-HEADEND#
*Mar  1 03:19:21.171: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.17.2.254 (Tunnel1) is up: new adjacency
GRE-HEADEND#sh ip eigrp neigh
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   172.17.2.254            Tu1               14 00:18:20   79  5000  0  81

As you can see above, the EIGRP has been stable for more than 15 minutes compared to the show ip eigrp neighbor output shown above.

I hope this has been helpful and I thank you for reading!

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Footer

WORK WITH US

Schedule a free consultation now!

LET’S TALK

Copyright © 2011–2023 · NetworkJutsu · All Rights Reserved · Privacy Policy · Terms of Use