Unable to ping using Gigabit Ethernet interface

[simonalle]

Hi. First time caller...

I have a Cisco 3845 router that we use for our access to the internet. We're migrating from bonded T-1s to a T-3. The T-3 arrives via copper and connects to a RiCi-T3 converter (think giant media-converter), and out comes an ethernet port, which is connected to my router.

I have configured the router interface (Gi0/1) with the IP address from the ISP (static IP) and netmask. I left the duplex, speed, media-type and negotiation to default values.

I am able to ping the interface with the IP address I assigned it and I can ping IP addresses like 8.8.8.8. using my current routing and the multilink T-1s. If I use the extended commands to ping using the Gi0/1 interface however, I get no response.

My ISP says they can see Layer 1 but no Layer 2 from our router. I am not sure if the RiCi is working correctly as it's a new piece of gear and I've not used it before. I did check my configuration with another engineer who has set these up in the past and he thinks I configured correctly.

I'll attach my running config (apologies as it's cluttered and needs to be cleaned.  I stole it from a VoIP/data gateway and just hacked the config until the T-1s bonded and worked.

Gene

config:

sh run
Building configuration...

Current configuration : 4174 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname xxxxxxxxx
!
boot-start-marker
boot-end-marker
!
card type t1 2
logging buffered 51200 warnings
!
no aaa new-model
!
resource policy
!
network-clock-participate wic 2
no network-clock-participate wic 3
ip subnet-zero
ip cef
!
!
!
!
ip domain name xxxxxxxx.local
isdn switch-type primary-dms100
voice-card 0
no dspfarm
!
!
!
voice call carrier capacity active
!
!
!
!
!
!
!
!
!
!
username
!
!
controller T1 0/2/0
framing esf
linecode b8zs
channel-group 0 timeslots 1-24
description
!
controller T1 0/2/1
framing esf
linecode b8zs
channel-group 0 timeslots 1-24
description
!
controller T1 0/3/0
framing esf
linecode b8zs
channel-group 0 timeslots 1-24
description
!
controller T1 0/3/1
framing esf
linecode b8zs
channel-group 0 timeslots 1-24
description
!
controller T1 2/0
shutdown
framing esf
linecode b8zs
cablelength long 0db
pri-group timeslots 1-24
!
controller T1 2/1
shutdown
framing esf
linecode b8zs
cablelength long 0db
pri-group timeslots 1-24
!
!
!
interface Multilink1
description Bonds all 4 T1's together
ip address xxx.xxx.xxx.42 255.255.255.252
no cdp enable
ppp multilink
ppp multilink group 1
!
interface GigabitEthernet0/0 (alternate interface config for testing)
description Connection to RICi-DS3
ip address xxx.xxx.xxx.xxx 255.255.255.0
duplex full
speed 100
media-type rj45
no negotiation auto
!
interface GigabitEthernet0/1
description RiCi-T3
ip address xxx.xxx.xxx.94 255.255.255.252
duplex auto
speed auto
media-type rj45
negotiation auto
!
interface GigabitEthernet0/0/0
description Connected to Data Distribution Switch
ip address xxx.xxx.xxx.1 255.255.255.0
shutdown
negotiation auto
!
interface GigabitEthernet0/1/0
description Connected to Voice Distribution Switch
ip address xxx.xxx.xxx.xxx 255.255.255.0
shutdown
negotiation auto
!
interface Serial0/2/0:0
no ip address
encapsulation ppp
no fair-queue
ppp multilink
ppp multilink group 1
!
interface Serial0/2/1:0
no ip address
encapsulation ppp
no fair-queue
ppp multilink
ppp multilink group 1
!
interface Serial0/3/0:0
no ip address
encapsulation ppp
no fair-queue
ppp multilink
ppp multilink group 1
!
interface Serial0/3/1:0
no ip address
encapsulation ppp
no fair-queue
ppp multilink
ppp multilink group 1
!
interface FastEthernet1/0
!
interface FastEthernet1/1
!
interface FastEthernet1/2
!
interface FastEthernet1/3
!
interface FastEthernet1/4
!
interface FastEthernet1/5
!
interface FastEthernet1/6
!
interface FastEthernet1/7
!
interface FastEthernet1/8
!
interface FastEthernet1/9
!
interface FastEthernet1/10
!
interface FastEthernet1/11
!
interface FastEthernet1/12
!
interface FastEthernet1/13
!
interface FastEthernet1/14
!
interface FastEthernet1/15
!
interface Serial2/0:23
no ip address
isdn switch-type primary-dms100
no cdp enable
!
interface Serial2/1:23
no ip address
isdn switch-type primary-dms100
no cdp enable
!
interface Service-Engine4/0
no ip address
shutdown
!
interface Vlan1
ip address xxx.xxx.xxx.202 255.255.255.248
!
ip default-gateway xxx.xxx.xxx.201
ip classless
ip route 0.0.0.0 0.0.0.0 Multilink1
!
ip http server
ip http access-class 23
ip http authentication local
ip http timeout-policy idle 60 life 86400 requests 10000
!
access-list 7 permit xxx.xxx.xxx.0 0.0.0.31
!
!
!
control-plane
!
!
!
!
!
!
!
!
call-manager-fallback
max-conferences 8 gain -6
transfer-system full-consult
ip source-address xxx.xxx.xxx.1 port 2000
max-ephones 24
max-dn 48
transfer-pattern ....
keepalive 10
!
!
line con 0
login
stopbits 1
line aux 0
stopbits 1
line 258
no activation-character
no exec
transport preferred none
transport input all
transport output all
line vty 0 4
access-class 23 in
privilege level 15
login
transport input telnet
line vty 5 15
access-class 23 in
privilege level 15
login
transport input telnet
line vty 16 1052
login
!
scheduler allocate 20000 1000
!
end

[jdwilliams803]

Looking at your configs: "ip route 0.0.0.0 0.0.0.0 Multilink1" you still have your traffic defaulted out the Multilink [T1 interfaces]. Consider adding the routes for [test] traffic you want to go out the Gi0/1 interface  or redirect the all traffic with "ip route 0.0.0.0 0.0.0.0 Gi0/1". You should be able to use: "sho ip route" to view the way your traffic is being sent immediately after you initiate the command to determine if it is being routed the way you want.

[Richard Burts · Accepted solution]

ip route which points just to the outbound interface is fine when it points to a point to point interface such as the multilink. But it is problematic when it points to an Ethernet interface. When Gene does change the route statement he should be careful to point to the IP address of the provider device.

Trying to test the new interface using extended ping through the existing multilink is not a very good test. For one thing the ping packet would go out through the multilink, but the response would be sent through the T3 since the T3 address was the source address of the packet. The asymmetry could be a problem. There is also some possibility that the address assigned from the T3 is not reachable from the multilink ISP.

I would suggest a different approach to testing. Start with show interface and make sure that it looks like the new T3/Ethernet is operational. Assuming that it looks good then attempt a ping to the provider address. If it works then you have demonstrated that the interface is functional and has IP connectivity. If the ping does not work then I suggest turning on debug for arp. With the debug running try the ping to the provider address again. Look into the debug output. You should see your router sending arp requests. Look to see if the provider is sending arp responses. If the provider is not sending arp responses then it does suggest that there may be layer 2 problems.

HTH

Rick

[simonalle]

Richard--turned on 'debug arp' and tried a ping to a known good outside IP. I used the extended commands to select the gigabit interface. I can see an immediate ARP request but it's using the network associated with the multilink1 interface, not the new network for the T3. 

Here's the output...

xxxxx#ping
Protocol [ip]:
Target IP address: 8.8.8.8
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: xxx.xxx.xxx.94
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
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 xxx.xxx.xxx.94

*Jul 20 15:43:01.203: IP ARP: creating incomplete entry for IP address: xxx.xxx.xxx.201 interface Vlan1
*Jul 20 15:43:01.203: IP ARP: sent req src xxx.xxx.xxx.202 001c.f61f.6ff0,
dst xxx.xxx.xxx.201 0000.0000.0000 Vlan1.....
Success rate is 0 percent (0/5)

[Richard Burts]

Gene

That arp activity appears to be normal traffic on vlan 1 and does not seem to have anything to do with your testing. Please do not test by using extended ping to ping 8.8.8.8. Please do what I asked before and ping to the provider address on the Gig interface.

HTH

Rick

[simonalle]

The ISP's router does not support ICMP replies (according to the test engineer I've been working with). I used 8.8.8.8 as the target as I know it's reachable.

[Richard Burts]

Gene

At this point I do not really care whether their device supports ICMP response (though I find it very odd that a networking device does not support ICMP response). What I care about is making sure that your router sends an arp request and whether they respond to the arp request. At this point the test is really about whether you have connectivity at layer 2. Once we get layer 2 straightened out then we will worry about layer 3.

If it bothers you to try to ping them when they do not support ping response then configure a host specific route for 8.8.8.8 which specifies the next hop as the provider address and then ping 8.8.8.8. This should generate an arp request for their address. The important thing is that we find out if you can send packets out the Gig interface and whether the provider sends something back.

HTH

Rick

[simonalle]

Richard, since my ARP requests aren't getting a reply from the gigabit interface with the MAC, I think my problem is 'upstream' from my interface, somewhere in the T-3. I was concerned that it might be the 0/1 interface so I swapped to the 0/0 interface and have the same issue.

[Richard Burts]

Gene

I would agree that this does suggest that the problem is upstream from you.

A thought that occurs is that you might check with them about whether the cable for the connection should be straight through or cross over.

HTH

Rick

[simonalle]

Thought about it and tried to ping the ISP router: here's the result

xxxxxxx#debug arp
ARP packet debugging is on
xxxxxxx#ping
Protocol [ip]:
Target IP address: xxx.xxx.252.93
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to xxx.xxx.252.93, timeout is 2 seconds:

*Jul 20 16:34:10.671: IP ARP: creating incomplete entry for IP address: xxx.xxx.252.93 interface GigabitEthernet0/1
*Jul 20 16:34:10.671: IP ARP: sent req src xxx.xxx.252.94 001c.f61f.6ff1,
dst xxx.xxx.252.93 0000.0000.0000 GigabitEthernet0/1.
*Jul 20 16:34:12.671: IP ARP: sent req src xxx.xxx.252.94 001c.f61f.6ff1,
dst xxx.xxx.252.93 0000.0000.0000 GigabitEthernet0/1.
*Jul 20 16:34:14.671: IP ARP: sent req src xxx.xxx.252.94 001c.f61f.6ff1,
dst xxx.xxx.252.93 0000.0000.0000 GigabitEthernet0/1.
*Jul 20 16:34:16.671: IP ARP: sent req src xxx.xxx.252.94 001c.f61f.6ff1,
dst xxx.xxx.252.93 0000.0000.0000 GigabitEthernet0/1.
*Jul 20 16:34:18.671: IP ARP: sent req src xxx.xxx.252.94 001c.f61f.6ff1,
dst xxx.xxx.252.93 0000.0000.0000 GigabitEthernet0/1.
Success rate is 0 percent (0/5)