cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2197
Views
0
Helpful
13
Replies

STATIC ROUTES WEIRD THINGS HAPPENING

iamtheone12345
Level 1
Level 1

Hi guys,

I am experiencing weird pehenomenon in packet tracer 5.

i have 2 routers connected to each other and themselves connect to a lan each.

PC1               ------------------------------------------------R1-----------------------------------------------------------R2------------------------------------------  PC2

(192.168.1.2)                          (FA0/0(192.168.1.1))(S1/0(20.1.1.1))                    (S1/0(20.1.1.2))(FA0/0(192.168.2.1))                  (192.168.2.2)             

I have configured a static route in R1

==============================

ip route 192.168.2.0 255.255.255.0 s1/0

I have configured a static route on R2

===============================

ip route 192.168.1.0 255.255.255.0 s1/0

Now i have changed the ip address of s1/0 of R2 from 20.1.1.2 to 40.1.1.2. I expect both the PC's on each end to ping each other as the static route to

192.168.2.0 from R1 points to R1's exit interface.As expected both PC's can ping each other.However the routers cant ping each other.I am little baffled

that it should have worked but its not .

This is the trace from one of the PC's to another PC.


PC>tracert 192.168.2.2

Tracing route to 192.168.2.2 over a maximum of 30 hops:

  1   32 ms     31 ms     31 ms     192.168.1.1
  2   41 ms     62 ms     62 ms     40.1.1.2
  3   94 ms     94 ms     79 ms     192.168.2.2

Clearly the trace from PC1 for PC2 goes through R1 .

But R1 somehow cant ping R2.

Is there any logic behind it or its just another packet tracer bug.

if any one wants the packet tracer file i can provide that.

Regards,

Arjun Das

1 Accepted Solution

Accepted Solutions

Arjun Das

When R1 attempts to ping to the PC2 the problem is not on R1 sending the ping but the problem is on R2 attempting to send the response.

R1 sends the ping packet and uses its route to 192.168.2.0 and sends the ping packet to R2 and the source address of the ping will be R1 serial address of 20.1.1.1. R2 forwards the ping packet to PC2 and PC2 builds a ping response which will have destination address of 20.1.1.1. PC2 sends the ping response packet to R2 and R2 does not know where address 20.1.1.1 is and drops the packet.

To fix this R1 would need a static route for 40.1.1.0 and R2 would need a static route for 20.1.1.0.

HTH

Rick

HTH

Rick

View solution in original post

13 Replies 13

Reza Sharifi
Hall of Fame
Hall of Fame

Hi,

Can you post the configs for both sides of the serial interface?

       PC1 ----------------------------------------R1-----------------------------------------R2----------------------------------------------pc2

(192.168.1.2)         fa0/0---> (192.168.1.1)S1/0--> (20.1.1.1)        S1/0-->(40.1.1.2)(FA0/0(192.168.2.1))   (192.168.2.2)

PC1--->192.168.1.2

R1

=========

FA0/0  192.168.1.1

S1/0     20.1.1.1

R2

=========

S1/0     40.1.1.2

fa0/0    192.168..2.1

PC2---->192.168.2.2

Arjun Das

This is a fairly simple situation. As you have mentioned the access from PC to PC still works because the static route specifies the outbound interface. So when you change the IP address of R2 serial interface it does not impact connectivity from PC to PC.

But it does impact connectivity from router to router. On R1 when you enter the command ping 40.1.1.2 R1 will look to see where that address can be reached. And R1 does not know how it can be reached. You can confirm this by doing show ip route on R1. It believes that the subnet on its serial interface is 20.1.1.0 and does not know where network 40.1.1.0 is located. If you put a static route on R1 for 40.1.1.0 pointing to the outbound interface (and a similar static route on R2 for the return traffic)  then R1 and R2 would be able to ping each other again.

HTH

Rick

HTH

Rick

Hi Richard,

well.I am missing something here.The tracert from PC1 to PC shows that it is going through R1.That means the router

doesn know the route to 192.168.2.0 network.I undersatnd your point that R1 doesnot know the route to 40.1.1.2 which is the s1/0 interface of R2.however,R1 is not being able to ping PC2 either.Now why is that ??

R1#ping 192.168.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R2#show ip route

Gateway of last resort is not set

     20.0.0.0/24 is subnetted, 1 subnets
C       20.1.1.0 is directly connected, Serial1/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
S    192.168.2.0/24 is directly connected, Serial1/0

clearly there is a route from R1 to 192.168.2.2 network.

regards,

Arjun Das

Please ignore the last post

======================

Hi Richard,

well.I am missing something here.The tracert from PC1 to PC2 shows that it is going through R1.That means the router

does know the route to 192.168.2.0 network.I undersatnd your point that R1 doesnot know the route to 40.1.1.2 which is the s1/0 interface of R2.however,R1 is not being able to ping PC2 either.Now why is that ??

R1#ping 192.168.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R2#show ip route

Gateway of last resort is not set

     20.0.0.0/24 is subnetted, 1 subnets
C       20.1.1.0 is directly connected, Serial1/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
S    192.168.2.0/24 is directly connected, Serial1/0

clearly there is a route from R1 to 192.168.2.0 network.

regards,

Arjun Das

Arjun Das

When R1 attempts to ping to the PC2 the problem is not on R1 sending the ping but the problem is on R2 attempting to send the response.

R1 sends the ping packet and uses its route to 192.168.2.0 and sends the ping packet to R2 and the source address of the ping will be R1 serial address of 20.1.1.1. R2 forwards the ping packet to PC2 and PC2 builds a ping response which will have destination address of 20.1.1.1. PC2 sends the ping response packet to R2 and R2 does not know where address 20.1.1.1 is and drops the packet.

To fix this R1 would need a static route for 40.1.1.0 and R2 would need a static route for 20.1.1.0.

HTH

Rick

HTH

Rick

Hi Richard,

Thanks.Just after i posted the last message i knew what i was missing.The route back for ping packet.Thank you very much for pointing me to the right direction.

I wanted to know another thing.Is it true that serial links between 2 routers (like  R1 and R2 here) with ppp encapsulation

doesnt require serial interfaces on either side to have ip addresses configured for PC1 to ping PC2 ?

Regards,

Arjun Das

Try this:

take the static routes pointing to remotes IP subnets and remote serial interface subnets out from both routers and configure encapsulation ppp on both serial interfaces and check if you can ping from routers or remote PCs or from PC to PC: Ping should fail  "PPP encapsulation has inserted remote host routes in the routing table".

Now: configure two static routes pointing to remote IP subnets only on both the routers and (no route to remote serial interface IP subnets) check if ping is successfull from PC to PC and from router to PC it should be successful.

Now, enter "no peer neigh route" under both serial interfaces and do shut/no shut, now ping from routers, it should fail but PCs still can ping each other: This is where you may configure static routes towards serial itnerface IP subnets.

Both routers need route toward the remote Lans for PC to PC and route towards remote serial interface IP subnets are required for routers to ping remote Lan as your ip subnets on serial interfaces are different.

When you configure "encap ppp" do sh ip route and when you do "no peer neigh route" & shut/no shut, do sh ip route and check the difference.

So you need routes towards the remote Lans on routers anyway for PC to PC or from router to PC.

You need to have routes towards remote serial interface IP subnets if routers need to ping remote PCs in this case. this you can attain through static routes or through encap ppp with default settings.

In my experience if you configure serial interfaces on both routers with encapsulation ppp and do not configure any IP address on either serial interface then the routers will not process IP on the serial interface and neither the PCs nor the router would be able to ping over the serial interfaces.

In my experience the closest you can get to having no IP address on the interface is to configure both serial interfaces with ip unnumbered. With unnumbered you do not configure a unique IP address on the serial interface and you point to an IP address on another interface of the router. This does not require a specific IP address on the serial interface, does not require an IP subnet between the routers, and allows the routers to send IP packets over the serial interfaces.

HTH

Rick

HTH

Rick

Hello Rick,

I fully agree. I have once tested myself whether it would be possible to not configure a serial point-to-point link with any address and still route IP packets over it by means of a static route pointing out these interfaces. As expected, it did not work - the IP processing is deactivated on an interface that has no IP address configured, and the static route out an IP-unconfigured interface was not even installed into the routing table. I do not think that a particular encapsulation would make a difference here: both HDLC and PPP would fail at this.

Best regards,

Peter

A route towards a destination must exist in the routing table either pionting towards a next hop or local interface for a router.

Sajid,

Sure I haven't stated anything different. But I do not understand the context - can you please be more specific?

Best regards,

Peter

Peter,

Sure , we both are saying the same thing.I should have read your whole statement,

"the static route out an IP-unconfigured interface was not even installed into the routing table".

Review Cisco Networking for a $25 gift card