4431 Routes some traffic

[FS_Sensors]

I have a newly installed Cisco 4431 that is exhibiting some odd behavior. From the router itself, I can ping 8.8.8.8 and from the router webpage, I am able to "Test WAN Connection" to 8.8.8.8 and get all green.

From clients behind the router, from command prompt, I can issue a ping google.com command and it will resolve an IP adress, however the pings time out. I can successfully ping yahoo.com from the same PC. If I try to ping 8.8.8.8 it times out. 

For testing, I have a laptop directly connected to g0/0/3, with ip x.x.x.238 and GW x.x.x.233

Needless to say, I am somewhat baffled by what seems to work arbritarily and what doesn't. Config posted below, any help appreciated!

Version is Cisco IOS XE 16.09.02

version 16.9
service timestamps debug datetime msec
service timestamps log datetime msec
platform qfp utilization monitor load 80
no platform punt-keepalive disable-kernel-core
!
hostname Router
!
boot-start-marker
boot-end-marker
!
!
vrf definition Mgmt-intf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
enable secret 5 $1$
!
aaa new-model
!
!
aaa authentication login default local
!
!
aaa session-id common
!
ip name-server x.x.x.x x.x.x.x
ip domain name xxxx.xxx
!
subscriber templating
!
multilink bundle-name authenticated
!
!
crypto pki trustpoint xxxxx
!
license udi pid ISR4431/K9 sn xxxxxxx
no license smart enable
diagnostic bootup level minimal
!
spanning-tree extend system-id
!
!
!
username xxxx privilege 15 secret 5 $1$
!
redundancy
mode none
!
!
interface GigabitEthernet0/0/0
description Outside
ip address x.x.x.38 255.255.255.240
negotiation auto
!
interface GigabitEthernet0/0/1
description unused
no ip address
shutdown
negotiation auto
!
interface GigabitEthernet0/0/2
description Fiber1
no ip address
negotiation auto
service instance 800 ethernet
encapsulation untagged
bridge-domain 800
!
!
interface GigabitEthernet0/0/3
description Fiber2
no ip address
negotiation auto
service instance 800 ethernet
encapsulation untagged
bridge-domain 800
!
!
interface GigabitEthernet0
description Mgmt Interface
vrf forwarding Mgmt-intf
no ip address
negotiation auto
!
interface BDI800
ip address x.x.x.233 255.255.255.248
!
ip forward-protocol nd
no ip http server
ip http authentication local
ip http secure-server
ip tftp source-interface GigabitEthernet0
ip route 0.0.0.0 0.0.0.0 x.x.x.33

ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0/0
!
ip ssh version 2
!
!
!
!
!
!
!
control-plane
!
!
line con 0
transport input none
stopbits 1
line aux 0
stopbits 1
line vty 0 4
logging synchronous level all
transport input ssh
!
ntp server 0.pool.ntp.org
!
!
!
!
!
end

[Richard Burts]

In looking through the config I notice that you have 2 static default routes

ip route 0.0.0.0 0.0.0.0 x.x.x.33

ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0/0

My guess is that one works and one does not and that some traffic is sent using the working one while other traffic is sent using the one that does not work.

While both default routes may look like they are equivalent (they would both send traffic out the same interface) the one that specifies only the outbound interface will require that the router arp for every destination address for which is is trying to forward. And that only works if the ISP supports proxy arp - and many ISP do not support that because of the potential security issue it raises. So my suggestion is to remove that static default route and tell us if the behavior changes.

[FS_Sensors]

Thanks Rick,

I went ahead and removed the default route to g0/0/0, saved the config, did a reload and verified the line was gone. I am still seeing the same behavior. I am going to try and do some packet captures to see if that sheds some more light on the issue.

As a side note, the route to int g0/0/0 was added by the web gui. It needed to know the "wan interface" to do the wan connectivity check.

Any additional thoughts appreciated.

[Richard Burts]

Thanks for the additional information. It is interesting that the gui added the static route specifying only the outbound interface. At best it is a less effective approach and would make the router work harder. At worst it could actually force some traffic to fail. So it is best that it is removed. 

I understand the desire to protect sensitive information but identifying all the addressing as x.x.x.<some number> makes it difficult for us to understand what is going on. For each of the addresses could you at least clarify whether the address is in class A or B or C and whether it is a public IP or a private IP?

I notice that there is no address translation configured. Is there no need for address translation? Is the ISP providing address translation?

[paul driver]

Hello

Just to add to @Richard Burts  comments. why do you have bridging enabled what is the requirment for this?

[FS_Sensors]

Gentlemen,

Thanks for your assistance. The router sits between class B and class C public subnets. The outside interface is 190.x.x.38/28, the inside interface is 200.x.x.233/29. There are several servers with public IPs on the /29 and there is another router downstream that NATs.

Running traceroute from the 4431 seems to have revealed the issue.

Running

/# traceroute 8.8.8.8 source x.x.x.38 (outside interface)
Gets there in 11 hops.

Running

/# traceroute 8.8.8.8 source x.x.x.233 (inside interface)

Stops returning pings after 5 hops.

It appears that the router at the 6th hop doesn't have a route back to my subnet. I am reaching out to the ISP. For the sites that I am able to access, the router at the 6th hop is different. The first 5 hops are always the same for everything I have run traceroute on so far.

With regards to bridging, there are two fibers that ran to different buildings with servers on that public subnet. I have since consolidated those servers in a single location and have two redundant fibers running LACP.

[Richard Burts]

Thanks for letting us know that your traceroute seems to have identified the issue. That was a good approach to testing.