Making a static route better than directly connected i/f

[shahedvoicerite]

Hi,

I have a situation, where I need to make a static route better than a directly connected interface.

My rather unusual situation is :-

Router has

1 FastEthernet : 10.1.1.0/24

1 VLAN (vlan1) : 192.168.1.0/24

(4 port switch on hwic)

Now I need to add a static route to 192.168.1.81/24 via 10.1.1.1

192.168.1.81 is a server on a routed network over the internet.

I cant use

ip route 192.168.1.81 255.255.255.255 fe0/1

because I need a next-hop gateway as well.

If I use

ip route 192.168.1.81 255.255.255.255 10.1.1.1

It works for Fe0/1, but not for packets originating from VLAN1.

(I believe they look for 192.168.1.81 on the local segment as admin distance is 0)

I could re-ip my vlan to 192.168.2.0, which I know would solve my problem, but there are some application depenedencies, which prevent me from doing so.

Thanks

[attrgautam]

I believe these are exactly the kind of situations proxy-arp would address. Try enabling proxy-arp on the VLAN 1 , ideally the router should reply back with its arp. Can you try it out ?

[mheusinger]

Hi,

I just wonder as proxy-arp is enabled per default!?

I would assume the host route combined with proxy-arp can do the trick. Still you have the same issue with the return path, i.e. why should 192.168.1.81 send the packets back to the router in the first place as it also must assume the hosts to be local. Another idea would be bridging between the two segemnts. Or you use NAT, which seems to me the best approach if IP renumbering is not an option. Basically you break the main assumption of all involved hosts about the term LOCAL area network (LAN).

So replace 192.168.1.81 by some unused IP like 172.16.1.81 and adjust your applications to use this IP. and NAT your loacal 192.168.1.0/24 to f.e. 172.17.1.0/24 for the 192.168.1.81 host.

Hope this helps! Please rate all posts.

Regards, Martin

[shahedvoicerite]

Hi,

proxy-arp is enabled by default.

On a host on the 192.168.1.0 network, when I try and ping 192.168.1.81, I see in the hosts arp cache,

the mac-address of vlan1

Interestingly, the mac-address of vlan1 is the same as that of fe0/0, which is a shutdown interface.

So the packets are going to the router ok.

But on the router itself, the IP address of vlan 1 is 192.168.1.87, so what happens to the packet next ?

On the router, when I

ping 192.168.1.81 source 192.168.1.87, it fails !!

When I ping with a source of 10.1.1.51 (IP address of FE 0/1) , it works (as expected)

Thanks

[attrgautam]

Ok then I think it is more of a routing issue, what about the other end ? What is the subnet mask for the 81 server there ? That should give us more clues especially as you are learning the arp correctly. Can you also give the output of sh ip ro 192.168.1.81

[shahedvoicerite]

The setup on the router is

192.168.1.87 (VLAN1) <-----eth on 4port HWIV---> Linux 192.168.1.233

10.1.1.51 (FE 0/1) <----eth----> gateway 10.1.1.1

My aim is to be able to reach 192.168.1.81 from 192.168.1.233

The subnet mask of 192.168.1.81 on the other end is /24. Its a cisco router routed via 10.1.1.1 over a vpn.

arp on 192.168.1.233 shows mac-address of vlan1

Perhaps, 192.168.1.81 cannot return back to me when I send ICMP packets out 192.168.1.87 interface.

But what about telnet ? Does that also require the target host to have a path back ?

output of sh ip ro 192.168.1.81 is :-

Routing entry for 192.168.1.81/32

Known via "static", distance 1, metric 0

Routing Descriptor Blocks:

* 10.1.1.1

Route metric is 0, traffic share count is 1

Output of sh ip ro 192.168.1.91 longer-prefiex is

Gateway of last resort is not set

192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks

S 192.168.1.81/32 [1/0] via 10.1.1.1

C 192.168.1.0/24 is directly connected, Vlan1

Output of ping 192.168.1.81 is

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.81, timeout is 2 seconds:

!!!!!

Output of ping 192.168.1.81 source 192.168.1.87 is

Sending 5, 100-byte ICMP Echos to 192.168.1.81, timeout is 2 seconds:

Packet sent with a source address of 192.168.1.87

....

Output of sh ip int brief is

FastEthernet0/0 unassigned YES NVRAM administratively down down

FastEthernet0/1 10.1.1.51 YES NVRAM up up

FastEthernet0/0/0 unassigned YES unset up up

FastEthernet0/0/1 unassigned YES unset up down

FastEthernet0/0/2 unassigned YES unset up up

FastEthernet0/0/3 unassigned YES unset up up

Vlan1 192.168.1.87 YES NVRAM up up

Vlan2 172.16.1.1 YES NVRAM up down

Loopback1 1.1.1.1 YES NVRAM up up

Thanks.

[mheusinger]

Hi,

as I wrote, you will have the same issue on the remote segment (i.e. with host 192.168.1.81). Routing wise the host route will work, because of longest match kicks in. the return traffic is a much bigger problem, because you need a /24 and longest match might just not be possible. And I do not know if you have any address overlap, i.e. two hosts with identical IP. Assume you have 192.168.1.10 on both segments. Then even with proxy arp there will be no return traffic from 192.168.1.81, because it will find the host locally.

In case you have no IP overlap, you could apply proxy-arp and host routes throughout your network to allow traffic for BOTH directions.

Again, NAT seems to be the "cleanest" and most simple solution, IMHO.

Regards, Martin

[shahedvoicerite]

Hi Martin, I think your explanation is very accurate.

Just 1 follow up. You say BOTH directions.

For telnet is not just 1 direction ok ?

What about rtp ? I remember a case where I had 1 way audio issues as the target phone did not have a gateway set.

Or perhaps TCP requires BOTH ways and not UDP ?

Thanks

[mheusinger]

Hi,

for TCP you definately need bidirectional communication (TCP 3-way handshake etc.) and for practically every application around you need bidirectional communication.

Why would you send IP packets to 192.168.1.81 in the first place, when you never expect it to answer. OK, there are examples like SNMP traps (uses UDP), but in any realistic case I know of you need bidirectional communication - TCP or UDP makes no difference.

Regards, Martin

[shahedvoicerite]

Hi Martin,

Thanks for the explanation.

But just from an academic point of view, when I try and send pings, even though there is no return path, I should still see the packets on the other end right ?

I did a sh ip traffic on 192.168.1.81 , and dont see any icmp packets recieved at the other end, when I do an extended ping from interface 192.168.1.87.

I do see 5 packets when I ping from the 10.1.1.51 address.

Perhaps I am missing something fundamental here !

Thanks

Shahed

[devang_etcom]

hi...

TCP always dealing with the reliable communication... it means when ever sender send the data then it will looking for the ACK from the receiver in order to sure that data send by the sender is received at the receiver end...in proper order... so here you need to have two directional communication one for transfer and other for ACK...

and in TCP protocol both the end first of all handshake with each other prior to transfer the data... so it must be in both the direction...if your receiver is not ACK the data send by the TCP then it use the TIMEOUT parameter to send the data again which is not good... and its also introduce the load on network...

where as UDP is unreliable...UDP just start to send the data with out worring about ACK... there is no ACK response from the client... so UDP just start sending the packet one by one and dont need ACK to make sure the relible communication...

so its up to application whether it want relible communication the it will go for TCP... but reliability is not a metter and only speed concern then you can have UDP as it save time as there is no ACK mechanism...

hope this will clear your idea

regards

Devang

rate this post if it helps