01-31-2022
01:25 AM
- last edited on
01-31-2022
09:59 PM
by
Translator
I've been trying to figure this out for a while, but nothing I've tried has worked.
I have a network storage device on a subnet that is having issues reaching the internet. It sits behind a Cisco 2911 router which is itself connected to a Linksys LRT214. The LRT214 acts as the gateway to the ISP. Any device on the local network can reach the network storage device through the LRT 214 without any meaningful packet loss, but the storage device cannot reach the internet for updates due to significant packet loss. I've been able to isolate the issue to being an issue with the two routers, but I have no idea what could be causing it.
Included below are the router config and ping results.
Current configuration : 3075 bytes
!
! Last configuration change at 09:10:12 UTC Mon Jan 31 2022 by snaperkids
version 15.2
no service timestamps debug uptime
no service timestamps log uptime
service password-encryption
!
hostname WeissSchnee
!
boot-start-marker
boot system flash:c2900-universalk9-mz.SPA.152-4.M6a.bin
boot-end-marker
!
!
security passwords min-length 8
enable secret 5
enable password 7
!
no aaa new-model
!
ip cef
!
!
!
ip dhcp excluded-address 192.168.33.1 192.168.33.32
ip dhcp excluded-address 192.168.33.1 192.168.33.64
!
ip dhcp pool LanPool
network 192.168.33.0 255.255.255.128
default-router 192.168.33.1
dns-server 8.8.8.8
!
!
!
no ip domain lookup
ip domain name WeissSchnee.local
login block-for 120 attempts 3 within 60
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
license udi pid CISCO2921/K9 sn FCZ154270GH
!
!
username snaperkids secret 5
!
redundancy
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Embedded-Service-Engine0/0
no ip address
shutdown
!
interface GigabitEthernet0/0
description Link to Internet
ip address 192.168.1.11 255.255.255.0
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
!
interface GigabitEthernet0/1
description Link to LAN
ip address 192.168.33.1 255.255.255.128
ip nat inside
ip rip send version 2
ip virtual-reassembly in
duplex auto
speed auto
!
interface GigabitEthernet0/2
description Link to RubyRose
ip address 192.168.33.249 255.255.255.252
ip nat inside
ip virtual-reassembly in
duplex auto
speed auto
!
interface FastEthernet0/1/0
no ip address
shutdown
!
interface FastEthernet0/1/1
no ip address
shutdown
!
interface FastEthernet0/1/2
no ip address
shutdown
!
interface FastEthernet0/1/3
no ip address
shutdown
!
interface FastEthernet0/1/4
no ip address
shutdown
!
interface FastEthernet0/1/5
no ip address
shutdown
!
interface FastEthernet0/1/6
no ip address
shutdown
!
interface FastEthernet0/1/7
no ip address
shutdown
!
interface FastEthernet0/1/8
no ip address
shutdown
!
interface Vlan1
no ip address
!
router ospf 1
router-id 1.1.1.1
redistribute rip subnets
passive-interface GigabitEthernet0/0
passive-interface GigabitEthernet0/1
network 192.168.33.0 0.0.0.127 area 1
network 192.168.33.248 0.0.0.3 area 1
default-information originate
!
router rip
version 2
redistribute ospf 1 metric 2
passive-interface GigabitEthernet0/1
network 192.168.1.0
network 192.168.33.0
neighbor 192.168.1.1
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
ip route 0.0.0.0 0.0.0.0 192.168.1.1
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0
!
!
access-list 1 permit 192.168.1.0 0.0.254.255
!
!
!
control-plane
!
!
banner motd ^C
<LEGAL DISCLAIMER>
:
^C
!
line con 0
password 7
login
line aux 0
line 2
no activation-character
no exec
transport preferred none
transport output none
stopbits 1
line vty 0 4
exec-timeout 5 0
password 7
login local
transport input ssh
!
scheduler allocate 20000 1000
!
end
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=168 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=116 time=26.6 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=116 time=27.4 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=116 time=22.7 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=116 time=18.9 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=116 time=20.9 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=116 time=27.0 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=116 time=31.6 ms
64 bytes from 8.8.8.8: icmp_seq=22 ttl=116 time=26.2 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=116 time=22.3 ms
64 bytes from 8.8.8.8: icmp_seq=28 ttl=116 time=35.1 ms
64 bytes from 8.8.8.8: icmp_seq=30 ttl=116 time=19.2 ms
64 bytes from 8.8.8.8: icmp_seq=32 ttl=116 time=20.7 ms
64 bytes from 8.8.8.8: icmp_seq=36 ttl=116 time=19.4 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=116 time=26.9 ms
64 bytes from 8.8.8.8: icmp_seq=40 ttl=116 time=30.0 ms
64 bytes from 8.8.8.8: icmp_seq=43 ttl=116 time=26.8 ms
64 bytes from 8.8.8.8: icmp_seq=45 ttl=116 time=17.6 ms
64 bytes from 8.8.8.8: icmp_seq=47 ttl=116 time=20.9 ms
64 bytes from 8.8.8.8: icmp_seq=51 ttl=116 time=26.7 ms
64 bytes from 8.8.8.8: icmp_seq=53 ttl=116 time=27.9 ms
64 bytes from 8.8.8.8: icmp_seq=55 ttl=116 time=18.6 ms
64 bytes from 8.8.8.8: icmp_seq=59 ttl=116 time=22.4 ms
64 bytes from 8.8.8.8: icmp_seq=61 ttl=116 time=28.7 ms
64 bytes from 8.8.8.8: icmp_seq=63 ttl=116 time=28.1 ms
64 bytes from 8.8.8.8: icmp_seq=67 ttl=116 time=21.7 ms
64 bytes from 8.8.8.8: icmp_seq=69 ttl=116 time=25.9 ms
64 bytes from 8.8.8.8: icmp_seq=71 ttl=116 time=27.0 ms
64 bytes from 8.8.8.8: icmp_seq=75 ttl=116 time=18.7 ms
64 bytes from 8.8.8.8: icmp_seq=77 ttl=116 time=20.7 ms
64 bytes from 8.8.8.8: icmp_seq=79 ttl=116 time=21.4 ms
64 bytes from 8.8.8.8: icmp_seq=83 ttl=116 time=43.2 ms
64 bytes from 8.8.8.8: icmp_seq=85 ttl=116 time=18.9 ms
64 bytes from 8.8.8.8: icmp_seq=87 ttl=116 time=19.1 ms
64 bytes from 8.8.8.8: icmp_seq=91 ttl=116 time=27.8 ms
64 bytes from 8.8.8.8: icmp_seq=92 ttl=116 time=21.1 ms
64 bytes from 8.8.8.8: icmp_seq=94 ttl=116 time=27.2 ms
64 bytes from 8.8.8.8: icmp_seq=98 ttl=116 time=22.4 ms
64 bytes from 8.8.8.8: icmp_seq=100 ttl=116 time=26.4 ms
Solved! Go to Solution.
01-31-2022
09:05 AM
- last edited on
01-31-2022
10:02 PM
by
Translator
Like @balaji.bandi I question the use of 2 default routes. The first one should be fine. But this one
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0
at best is not Best Practice and at worst could cause real problems (especially if the next hop does not support proxy arp). I suggest that you remove the second default route.
Would you post the output of
show interface G0/0 and of show ip interface G0/0.
How did you determine that the problem is due to packet loss?
Do other devices in your network have issues with packet loss or is this problem unique to the storage device?
Can you give us any information about the LRT214, especially about how its interface to your Cisco is configured?
01-31-2022
03:34 AM
- last edited on
01-31-2022
09:59 PM
by
Translator
Hello,
the storage server is connected directly to an interface on the router ?
Post the output of:
show interfaces x
where 'x' is the interface the server is connected to.
01-31-2022
05:07 AM
- last edited on
01-31-2022
10:01 PM
by
Translator
- what is the device IP address which you having issue, from what source that ping 8.8.8.8 posted from ?
May be i am reading wrong here ? - why do you need 2 Static routes her e
ip route 0.0.0.0 0.0.0.0 192.168.1.1
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0
!
access-list 1 permit 192.168.1.0 0.0.254.255
- is this subnet is correct ? you looking to do NAT /16 IP address range ? (which is also your outside IP address ?
Instead for testing do only Inside IP address for NAT and Test it ?
no access-list 1 permit 192.168.1.0 0.0.254.255
access-list 1 permit 192.168.33.0 0.0.0.255
is this possible ?
01-31-2022
09:05 AM
- last edited on
01-31-2022
10:02 PM
by
Translator
Like @balaji.bandi I question the use of 2 default routes. The first one should be fine. But this one
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0
at best is not Best Practice and at worst could cause real problems (especially if the next hop does not support proxy arp). I suggest that you remove the second default route.
Would you post the output of
show interface G0/0 and of show ip interface G0/0.
How did you determine that the problem is due to packet loss?
Do other devices in your network have issues with packet loss or is this problem unique to the storage device?
Can you give us any information about the LRT214, especially about how its interface to your Cisco is configured?
01-31-2022 05:24 PM
I intended to have the default route fully specified due to the static nature of the physical connections. I messed up the commands. I've since corrected it, and now I'm getting all echoes returned.
01-31-2022 11:33 PM
Thanks for confirming that the second static default route was the issue. Glad that things are now working. Thank you for marking this question as solved. This will help other participants in the community to identify discussions which have helpful information. This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide