cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1611
Views
0
Helpful
1
Replies

Can't ping internet addresses from inside networks on the CSR1000v

razorbakill
Level 1
Level 1

I have the CSR1000v setup and configured in AWS with what I thought should work. From the router I can ping google DNS of 8.8.8.8, with a simple command of "ping 8.8.8.8". But if I try to ping 8.8.8.8 form the inside interface address using the "ping 8.8.8.8 source 172.27.15.5" , it will not ping.

If I create a loop back address, say 172.16.0.50 and try to do a ping from source with this address, again it will not ping. I can only ping from the private IP that is connected with the elastic public IP of AWS.

I then setup and configured a physical Cisco 1921 router the same way and had no issues pinging from the inside interface. I had no issues creating loopback addresses and then doing a Ping from loopback source addresses. It all works on a physical network.

I was told by the AWS tech that the inbound and outbound security settings on AWS are set to 0.0.0.0/0 to any. Just figuring to have it wide open.

Has anybody ran into this? I'm trying to figure out if this a router configuration issue or a AWS configuration issue.

Ping Tests are below...

I have attached the router configuration.

Any help would be appreciated..

Thanks

Router#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 11/12/13 ms

Router#ping 8.8.8.8 source 172.27.1.5  - GI0/1 Private IP connected to Elastic AWS Public IP
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 172.27.1.5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 11/11/11 ms

Router#ping 8.8.8.8 source 172.27.15.5 -  GI0/2 Inside Network Interface
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 172.27.15.5
.....
Success rate is 0 percent (0/5)

Router#ping 8.8.8.8 source 172.16.0.50 - Loopback 10 Interface
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 172.16.0.50
.....
Success rate is 0 percent (0/5)

Gateway of last resort is 172.27.1.1 to network 0.0.0.0

S*    0.0.0.0/0 [254/0] via 172.27.1.1
      xx.0.0.0/32 is subnetted, 1 subnets
S        xx.xx.xx.xx [1/0] via 172.27.1.1
      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
B        172.16.0.0/17 [20/0] via 192.168.0.1, 01:40:20
C        172.16.0.50/32 is directly connected, Loopback10
      172.27.0.0/16 is variably subnetted, 4 subnets, 2 masks
C        172.27.1.0/24 is directly connected, GigabitEthernet1
L        172.27.1.5/32 is directly connected, GigabitEthernet1
C        172.27.15.0/24 is directly connected, GigabitEthernet2
L        172.27.15.5/32 is directly connected, GigabitEthernet2
      192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/30 is directly connected, Tunnel0
L        192.168.0.2/32 is directly connected, Tunnel0

1 Reply 1

tbanuelo
Cisco Employee
Cisco Employee

Hello,

From the google server perspective (8.8.8.8), it would not have a return path to networks 172.16.0.50 and 172.27.15.5. The 172.27.1.5 address is NAT'ed by the AWS IGW EIP address and that is how a successful ping is possible. In this case, if you need 172.16.0.0 and 172.27.15.0 to reach the internet you will need to NAT these addresses via Ge1 or create a GRE tunnel down to your prem and advertise these subnets via your prem network to step off to inet

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: