Self ping serial interface

[saimbt]

Hi,

If we have 2 routers,

rtrA serial IP address 1.1.1.1

rtrB serial IP address 1.1.1.2

both the serial ports are connected through a leased line.

If i ping 1.1.1.1 from rtrA the delay is around 36ms, and if i ping 1.1.1.2 from rtrA the delay is around 18 ms,

i guess if i do a self ping on the serial interface, it goes till the next ip address and returns back.

also if the serial link is down, the self serial ip address is not able to ping itself.

kindly explain the logic behind it.

Sai.

[Kevin Dorrell]

Thanks Rick.

That wraps it up, except for one aspect of this conversation that we have not answered yet: the question posed by Kapish:

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.1dd6dc54/7#selected_message

I have never seen such a behaviour. Any ideas?

Kevin Dorrell

Luxembourg

[Richard Burts]

Kevin

I can think of several things that might explain the symptoms that Kapish describes:

- perhaps there was a keystroke error and he had actually typed the address of the neighbor router.

- perhaps he had used the broadcast address of the subnet. If a Cisco router receives a ping to the broadcast address it will generally send a unicast response.

- perhaps there was a firewall or proxy involved. I have seen networks set up where there is a firewall or some kind of proxy that does not allow things like ping go to external destinations and will generate a response back to the sender as if the ping had succeeded.

I guess we will never know for sure what was happening that time.

HTH

Rick

[kapishmohole.cisco]

What I did is, my public IP range is 212.102.85.176/30, and this means 212.102.85.177 is ISP router serial IP and 212.102.85.178 is my serial IP. So I was trying to ping both serial IPs from www.dnsstuff.com.

I was getting reply for 212.102.85.177 ISP router IP and also my serial IP 212.102.85.178 when line protocol was UP, that is OK.

But when I make my serial interface administratively DOWN, then also I was getting reply for both IPs!

ISP engineer gave the explanation; it’s because of their router (ISP router) reply behalf of my router! And there was a static route on ISP router for my network.

Even I didn’t get it properly, thought it many be because any feature of routing protocol or any command running on ISPs router.

At that time for testing purpose I was directly connected to my router, no firewall/proxy. And I tried this ping test for three-four times and got reply for it.

But I want to understand this.

[marikakis]

Ping works in a very specific way.

You have to ping somewhere "behind" your router

to be sure that the ping crosses your router.

If the ISP router for some reason sees the interface

that interconnects it with you in an up/up state,

it will respond on behalf of you.

So the question here is why the ISP router interface

does not go down when you shut your interface.

Depending on the setup, administratively shutting down an interface

might not be very well propagated to the other end.

How much time did you keep your interface in admin shut state?

Some setups need to detect loss of carrier in order to bring the peer interface down.

Could you please provide some more details concerning your setup?

Do you have ppp or hdlc encapsulation on your circuit?

Do you have keepalives enabled?

Is there a telco cloud that seperates you from the ISP?

M.

[marikakis]

PPP is the only layer-2-considered protocol that installs

a host route in the routing table for the IP address of the peer.

If you have a point-to-point circuit with PPP encapsulation,

in the routing table you will have the Connected subnet (normally /30)

and a host route (/32) to the IP address of the peer.

PPP is more network layer aware compared to HDLC.

Also, during loopback tests it is recommended to change

the encapsulation from PPP to HDLC.

The above led me to suspect that self ping could be different with PPP.

I thought perhaps PPP would know that on the other end

of the point-to-point circuit there is somebody else.

(I also wondered how this would work with /31 masks on the endpoints.)

If you tested that and confirmed the same behavior with both encapsulations,

I guess I was wrong.

Thank you for your reply,

M.

[Kevin Dorrell]

I am OT - again!

Maria,

Thanks for pointing out about PPP installing the host route. That ties up nicely with something I noticed with our dialup ISDN/PPP connections; that when someone dials in, our access router installs a host route for the remote end of the connection for the duration of the call. If I remember my observation correctly (which is always a dangerous way to do experiments), this was true even if the remote was using an IP address (fixed at the remote end by them) outside the configured subnet of our local interface.

I've got to think through the security implications of that. There is surely a way I can configure the dialer profile so it only accepts the PPP connection if I am happy with the IP address they are proposing. Otherwise a dialin could hijack traffic by using this behaviour to install host routes on the access router. I cannot remember the AD of host routes installed in this way, but I guess it is 1. In any case, if they are specific host routes, they could still override subnet routes learnt from a routing protocol.

Kevin Dorrell

Luxembourg

[marikakis]

Kevin, I wouldn't say your experiment was dangerous.

I would say it was pretty cool!

This way you discovered something I had to study a lot in order to spot ;-)))

PPP is designed to work with peers on any subnet,

and that's why this host route is installed.

It is supposed to allow communication between any two peers.

The peer IP address detection is the result of IPCP if I recall correctly.

If you turn on some debugs you will see somewhere the peers

spoting each other's IP addresses.

PPP is tied with some network layer protocols.

(I think there exists even a CDPCP for cisco CDP.)

M.

[marikakis]

Kevin, I forgot to say about the AD.

You are right, most specifics override.

I am not sure the AD is 1.

I would bet it is 0, i.e. the AD of Connected.

Since I do not have much money to lose in the bet,

someone could claim my bet is not very convincing :-)

So, I would be grateful if anyone could answer this.

M.

[Kevin Dorrell]

Maria,

I think you win the bet. I just had a look on our access router. Now, I have static host routes to the expected remote addresses of our dialin partners, each via their appropriate dialer profile. ("Belt and braces") Normally, static routes via interfaces are AD=0, and static routes via addresses have AD=1, if I remember right. At the time I looked, one of our partners had an active call in progress, and the static route had been replaced by a "connected" route. So it looks like in a competition between a static AD=0 and a connected AD=0, the connected wins. Which is what I could expect, because if you configure a static route the same as a connected, the connected wins.

It's like a connected has AD=-1.

Kevin Dorrell

Luxembourg

[marikakis]

A book claiming that the administrative distance for a static route pointing

to an outgoing interface is 0 has become quite common.

This misunderstanding probably derives from the misleading output

of the "show ip route" command, which uses the phrase "is directly connected"

either for C routes or S routes pointing out an interface.

Default administrative distance for a static route is always 1,

regardless if it points to a next hop IP address or to an outgoing interface,

as it is correctly said on the following URL:

http://www.cisco.com/en/US/tech/tk365/tk80/technologies_tech_note09186a0080094195.shtml

In fact, only connected (C) can supply routes with an AD of 0 to the routing table,

and I believe this is a very good choice that protects us from ourselves.

The S route is indeed accompanied by the phrase "is directly connected",

but that does not make it also have an AD of 0.

For instance, if we configure an S route using a local interface

and at the time of creation we also specify that it has an AD of 50,

the route will be displayed accompanied by the "is directly connected"

jargon, but the distance will be 50 and not the distance of C routes.

I have seen this mistake in the following books:

" Cisco Networking Academy Program CCNP 1: Advanced Routing

Companion Guide Second Edition"

" CCNP Self-Study CCNP BSCI Exam Certification Guide Third Edition" by Clare Gough

Clare Gough has made the same mistake in the past within the

CCNP Routing Exam Certification Guide.

I had seen that 3 years ago and was hoping by now she would have corrected it.

I recently couldn't help myself and sent e-mail to Cisco Press.

I got reply that they are in the process of adressing this issue.

Such things make me reluctant to take any tests.

In the process of studying some books,

I find myself "unlearning" stuff I have learned on the job :-(

I had to give a wrong answer to a question about the AD of statics on the CNAP CD-ROM,

so that I can get it right ;-)

Looking forward to seeing the corrected editions of these books.

M.

[marikakis]

BTW, the "is directly connected" jargon seen in the routing table

has to do with how the forwarding engine sees the routes,

and is not related to path selection according to AD.

M.

p.s. Sorry for not checking if the URL still works.

I have to search again for it.

[Kevin Dorrell]

Wow! There goes another pillar of my beliefs!

I shall not tell you which book I saw it in until I get home and can check my facts, but it wasn't any of the ones you mentioned! I'll try and do so over the weekend. (I'm at Networkers next week so I may not have time before I leave.)

When I was studying for my CCNA, I got sufficiently irritated with the book I was reading to make an errata sheet, which was considerably longer than the one published on the CiscoPress website, and I sent it to CiscoPress. They acknowledged it, but I don't think they ever posted it.

I agree with you fully about the floating statics - I tend to use floating statics quite liberally, and they have always worked for me. (Must remember not to do so in any future CCIE lab.) But there is a lesson there for anyone reading this who is taking a test soon: if the course material disagrees with reality, answer according to the course material.

I've also noticed how errors get propagated from book to doc and back again. It all sounds familiar - I don't know whether you read the long thread about the maximum hope [sic] count in EIGRP? (Please, no further discussion on that point!)

Kevin Dorrell

Luxembourg

[Kevin Dorrell]

Maria,

I found the info in "CCIE Routing and Switching Exam Certification Guide", Anthony Bruno, pages 476, 477 and 501, and believe-it-or-not, "Routing TCP/IP" Doyle on page 107.

Doyle's argument is that "If two static routes point to the same destination, but one references a next-hop address and one references an exit interface, the latter - with the lower administrative distance - will be preferred." Which seems reasonable ... but maybe there is a different mechanism going on there. And it still doesn't explain why a 'C' route installed by IPCP would take priority over an 'S' route to the dialer interface.

Is there any way to read the AD of C and S routes directly? I know it is possible for learnt routes, but it doesn't seem to be for Connected and Static.

BTW, Rick put me right about my security issue: how to prevent remote dialing from hijacking traffic by using IPCP to install a host route to themselves. It is no peer neighbor-route, which does not seem to be widely documented in the standard docs. Thanks again Rick. I found some doc here:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_configuration_guide_chapter09186a008008730a.html#4246

Kevin Dorrell

Luxembourg

[Richard Burts]

Kevin

If you do a show ip route for a specific static or connected route it will show the distance for the route:

router#sh ip route 172.17.24.3

Routing entry for 172.17.24.3/32

Known via "static", distance 1, metric 0

Redistributing via eigrp 1

Advertised by eigrp 1 route-map EIGRP_Allowed_Out

Routing Descriptor Blocks:

* 172.16.130.23, via Vlan913

Route metric is 0, traffic share count is 1

router#sh ip route 172.16.130.18

Routing entry for 172.16.130.16/28

Known via "connected", distance 0, metric 0 (connected, via interface)

Redistributing via eigrp 1

Routing Descriptor Blocks:

* directly connected, via Vlan913

Route metric is 0, traffic share count is 1

HTH

Rick

[Kevin Dorrell]

Thanks Rick,

Maria is right, and almost every book on my bookshelf (about 20-30 from CiscoPress) is wrong. A static route out an interface has an administrative distance of 1, not 0. Here is the proof on a 2509 IOS 12.1(1):

TS0#conf t

Enter configuration commands, one per line. End with CNTL/Z.

TS0(config)#ip route 192.168.41.128 255.255.255.252 Ethernet 0

TS0(config)#^Z

TS0#show ip route 192.168.41.129

Routing entry for 192.168.41.128/30

Known via "static", distance 1, metric 0 (connected)

Routing Descriptor Blocks:

* directly connected, via Ethernet0

Route metric is 0, traffic share count is 1

The only book on my shelf that got it right was "Troubleshooting IP Routing Protocols", page 25.

If I get the question in an exam, what to answer, the truth or the lie? I think I would grit my teeth and tell the lie.

Kevin Dorrell

Luxembourg