Pinging your local interface

darkmagic

Ok, i got it then, but then what is the internals that the commands goed through when we try to ping the local interface ?

2lazybutsmart

mayh3m wrote:

The same thing happens if you kill the keepalive (no keepalive), it's still up up, but cannot telnet or ping.

If you play with the keepalives, that takes the devices on the network segment off synch resulting in a data link problem. Consequently, that would give you an up/down.

darkmagic wrote:

2lazybutsmart wrote:

To sum things up: the nature of serial links being a point-to-point connection probably gives them these sensitive layer 3 attributes. There's only one physical network segment there anywayz.

Can you elaborate that a little bit, i am sorry to ask for it, but it isn't as clear to me, thanks...

What I mean is that when you have two serial interfaces connected together, you have a point-to-point link. And a p2p link is technically one physical network segment --one cable, means you can't have a third device on that same cable.


2lbs.

QUIX0TIC

I would like to officially recant my earlier statements. I finally got off my arse and wiped a couple of configs and just connected two routers back to back. They were able to ping each other blah blah blah.

Then I changed the subnet and I wasnt able to ping the local interface. So, I did my research and looked at the ip debug statements and the icmp packets were treating it like a typical loopback interface. But, since it was connected to the other router... the packets were hitting "router b" interface but were not getting routed back properly.

I confirmed this with our local network guy and he gave a longer expression of course... but he confirmed what I found. Hope this helps... sorry for the mis information earlier.

EdTheLad

Great Quixotic, this clears up the problem, i dont like it, but once i know this is a cisco feature, great.I like to ping my local interfaces while troubleshooting problems just to ensure the IP stack is working correctly on my local device.Now i know not to rely on this for Cisco serial interfaces.

QUIX0TIC

I also didnt add my apologies for misleading info regarding this issue. So, I apologize.

Anyways... now I need to find out why in the heck did it work on my serial interface originally.

Ten9t6

check this article out...it explains why you are seeing what you are seeing and ways to get around it...especially doing frame-relay. Enjoy....

http://tcpmag.com/qanda/article.asp?EditorialsID=223

Kenny

nick619

I guess cisco is different, I am able to ping my local interface if it's on a different subnet than the remote device it's connected to:


Here's a Juniper router:
Rtr1

---

FE

---

Rtr2
192.168.1.1/30 192.168.1.2/30

[edit]
root@Rtr1# run ping 192.168.1.1 count 2
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=7.465 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.313 ms

[edit]
root@Rtr2# run ping 192.168.1.2 count 2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=1.066 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.852 ms

Now, I change Rtr1 to 192.168.192.1/30 and leave Rtr2's interface alone:

[edit]
root@Rtr1# run ping 192.168.192.1
PING 192.168.192.1 (192.168.192.1): 56 data bytes
64 bytes from 192.168.192.1: icmp_seq=0 ttl=64 time=0.373 ms
64 bytes from 192.168.192.1: icmp_seq=1 ttl=64 time=0.247 ms

nick619

The reason the Juniper is able to ping:

[edit]
root@Rtr1# run show route 192.168.192

inet.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.192.0/30 *[Direct/0] 00:00:02
> via fe-0/0/0.0


There's a route pointed to that fe-0/0/0 interface in which 192.168.192.1/30 is configured.

.1 then replys to my ping

Not sure how cisco works however. Do you have a direct route in your routing table for that 12 network?

QUIX0TIC

Ten9t6 wrote:

check this article out...it explains why you are seeing what you are seeing and ways to get around it...especially doing frame-relay. Enjoy....

http://tcpmag.com/qanda/article.asp?EditorialsID=223

Kenny

Well, at least what or how I explained the loopback makes sense then.

EdTheLad

Yep, nice link from Kenny,so im assuming this that hdlc is using reverse arp
to learn about the neighbour ip address and doesnt know its local ip address because cisco were too lazy to implement this .
I've tryed to find info about slarp but its like looking for a needle in a haystack.Anyway in the end the mystery is solved.

2lazybutsmart

Is it using RARP to find out the neig's IP, or is it using RARP to find it's own MAC address? Looks like to latter to me.

Pretty similar to what dumb terminals due when then come into a network.

2lbs.

EdTheLad

Correct 2lbs, what would i do without you to correct me