Problem with network connectivity in one direction (pings one way not the other)

Can't seem to nail this issue down. Have a fairly simple setup


R1 and R2 are Cisco 3550 EMI (L3) switches 12.2.
R3 is Cisco 3660 Enterprise 12.3

R1 is in BGP AS 100
R2 & R3 are in BGP AS 200 adn EIGRP AS 300

R1 & R2 Running BGP
R2 & R3 Running EIGRP

Can ping between all routers (R1>R2, R1>R3, R2>R1, R2>R3in all directions except R3 to R1. It appears that the packets are getting routed properly to R2, but no response is getting back to R3.

I'm pulling my hair out. Nothing fancy in the configs is going on. Any ideas for a cause?
Who is Participating?
1gtxConnect With a Mentor Author Commented:
The quickest solution was to change the PTP network address for R2 to R3 to a subnet under X.X.140.X instead of That worked!

Though I still don't really understand why this was a problem I'll take a viable fix anyday. I'm awarding the point for the help.
Don JohnstonInstructorCommented:
A ping is bidirectional. Simply put, if R1 can ping R3, then R3 can ping R1.

The only thing that will cause the behavior you're describing is either a firewall or an access-list blocking the request in one direction or blocking reply in the other direction. Since there's no firewall between the two, it must be an ACL on one of the three routers. If you look, you'll probably find an ACL that is denying ICMP echo-requests or echo-replies somewhere.
1gtxAuthor Commented:
No ACLs used.

It appears to be some kind of routing problem, where the inbound packets for R3 are getting lost between R1 and R2. Can successfully ping from R3 to the inside interface of R1, but not to the outside one (a point to point link).

Maybe it's involves the transition from BGP to EIGRP and
Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

Don JohnstonConnect With a Mentor InstructorCommented:

Think about it like this:

R1 pings R3; Successful, right?

Step 1: R1 sends an ICMP echo-request. That packet arrives at R3.

Step 2: R3 creates and ICMP echo-reply. It checks it's routing table for R1's IP address. Matches it to an entry and sends the packet out.

Now R3 pings R1: The first thing R3 does is the exact same thing it did in step 2 above but it uses an ICMP echo-request instead of an echo-reply.

Now the ONLY way this could be a routing protocol is if you're pinging the far-side IP address as opposed to the near-side IP address of the router.
1gtxAuthor Commented:
You're right--I was pinging the far side IP address not the inside one.

That leaves a routing problem.

I can ping R1, R2, and R3 from the internet.

I can ping the internet from R1 and R2, but not R3.

This seems to lead to a possible issue with the route not propagating properly from BGP to EIGRP. Correct?

Don JohnstonInstructorCommented:
Going to have to see the routing table of R3 to go any further.
Have you tried to trace route R3 to R1??
1gtxAuthor Commented:
Trace route from R3 to R1 makes the first hop to R2 but then gets lost (stars)
Don JohnstonConnect With a Mentor InstructorCommented:
Going to have to see the routing table of R3 to go any further.
1gtxAuthor Commented:
Show ip route for R3:

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 to network

     X.X.0.0/32 is subnetted, 2 subnets
C       X.X.140.253 is directly connected, Loopback0
D       X.X.140.254
           [90/156160] via, 01:31:36, FastEthernet0/1 is subnetted, 2 subnets
D [90/30720] via, 01:31:36, FastEthernet0/1
C is directly connected, FastEthernet0/1
D*EX [170/258816] via, 00:01:33, FastEthernet0/1

X.X.140.253 is loopback for R3
X.X.140.254 is loopback for R2 is PTP addr for R2 to R1 is PTP addr for R2 to R3
Don JohnstonInstructorCommented:
Unfortunately, it's going to be rather difficult to troubleshoot without knowing the IP address you're trying to ping and what the routing table looks like.

1gtxAuthor Commented:
Pinging any address on the internet will fail for R3.

Interesting enough I did a debug ip packet and noticed that the IP being used as the source was the outbound interface IP of R3 ( and not the loopback address for R3 (which I thought was normal?!).

Lo and behold if you change the source IP for ping command on R3 to X.X.140.253 (the loopback addr for R3) pinging the internet from R3 works!

So I guess a quick and dirty approach would be to change the default source address for R3 to the loopback address. Though I'm not sure how to do that.

Don JohnstonInstructorCommented:
Once again... Impossible to say anything without knowing the addresses.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.