telnet while using interface secondary IP as a source IP

I have a following setup:

Cisco891[Gi0] <-> [Fa1/0/4]WS-C3750-48TS[Fa1/0/43] <-> [eth1]IBM_server

IBM_server eth1 has following configuration:

ifconfig eth1 10.10.10.1 netmask 255.255.255.0

Router configuration is following:

Cisco891#sh run int Gi0 
Building configuration...

Current configuration : 149 bytes
!
interface GigabitEthernet0
 ip address 10.10.10.2 255.255.255.0 secondary
 ip address 192.168.1.202 255.255.255.252
 duplex auto
 speed auto
end

Cisco891#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Cisco891(config)#int Loopback1234
Cisco891(config-if)#ip address 10.10.10.3 255.255.255.255
% 10.10.10.3 overlaps with secondary address on GigabitEthernet0
Cisco891(config-if)#

I need to telnet to 10.10.10.1(IBM_server) using the secondary address of Gi0(10.10.10.2) as a source IP address. As much as I have understood, it's not possible to specify source IP address in case of telnet. However, it's possible to specify source interface for telnet session. I tried to configure loopback interface for "telnet 10.10.10.1 /source-interface Loopback1234", but this doesn't seem to work either as you can see from my example above

Any ideas? Or is it possible to telnet while using interface secondary IP as a source IP?

Find more posts tagged with

Comments

JaCkNiFe

Cisco891(config-if)#ip address 10.10.10.3 255.255.255.255
% 10.10.10.3 overlaps with secondary address on GigabitEthernet0
Cisco891(config-if)#

This implies the interface rejected the configuration which can be verified with a 'show ip int bri'. You cannot have two interfaces on a router in the same subnet. Therefore your test "telnet 10.10.10.1 /source-interface Loopback1234" resolved an interface with no IP address.

Is this a lab environment?

The given:

If the 192.168.1.202/30 address was set to the secondary address and the 10.10.10.2/24 as the 'primary' IP address your telnet would resolve. Since your IBMserver does not have an address in the 192.168.1.200/30 subnet (let alone an ARP entry), it cannot return traffic to router Cisco891 which is using the 'primary' address as the source address for traffic headed out of this interface.

I don't believe there is a way to specify a source address specifically when establishing a 23 session.

Good luck mate!

Forsaken_GA

get rid of the secondary IP address on Gi0

Configure your loopback with 10.10.10.2

add a static route for 10.10.10.1/32 pointing out Gi0

then try your telnet command with the source interface again. That might work, it'll depend on the rest of the network. If that server and your router are in the same vlan, then it'll be fine. If the 3750 is doing any routing, then it's not going to work unless you configure the loopback as a /32 and advertise it to the 3750 (otherwise the 3750 won't have a route back to the 891, at least not out the interface that's connected to it)

If the 3750 isn't doing any routing and those boxes are in the same vlan, then whoever designed this setup needs to be shot for putting multiple subnets in the same vlan.

m4rtin

JaCkNiFe,
yes, it's for testing purposes.

Forsaken_GA,

Interfaces are configured like this:

Cisco891#sh run int Gi0
Building configuration...

Current configuration : 102 bytes
!
interface GigabitEthernet0
 ip address 192.168.1.202 255.255.255.252
 duplex auto
 speed auto
end

Cisco891#sh run int Loopback1234
Building configuration...

Current configuration : 67 bytes
!
interface Loopback1234
 ip address 10.10.10.2 255.255.255.0
end

Cisco891#

..and static route is done:

Cisco891#show ip route 10.10.10.1
Routing entry for 10.10.10.1/32
  Known via "static", distance 1, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via GigabitEthernet0
      Route metric is 0, traffic share count is 1
Cisco891#

..but in case I execute :

telnet 10.10.10.1 /source-interface Gi0

I can tcpdump ARP queries in IBM_server for 10.10.10.1 from source IP 192.168.1.202

Server and router are in the same VLAN.

Did I misunderstand you? Or such setup doesn't work..

instant000

What happens when you attempt to use source interface of that Loopback1234?

Loopback1234 is the interface you're attempting to use, correct?

as long as the Loopback interface has a route to that destination, it should work.

Let us know the results.

Forsaken_GA

m4rtin wrote: »
JaCkNiFe,
..but in case I execute :
telnet 10.10.10.1 /source-interface Gi0
I can tcpdump ARP queries in IBM_server for 10.10.10.1 from source IP 192.168.1.202

Well of course it's going to source from 192.168.1.202. You specified the source interface as Gi0 instead of the loopback, and that's the IP on Gi0.

Try sourcing it from the loopback instead

m4rtin

instant000, Forsaken_GA:

Unfortunately this does not seem to work:

Cisco891#sh run int Lo1234
Building configuration...

Current configuration : 67 bytes
!
interface Loopback1234
 ip address 10.10.10.2 255.255.255.0
end

Cisco891#show ip route 10.10.10.1
Routing entry for 10.10.10.1/32
  Known via "static", distance 1, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via GigabitEthernet0
      Route metric is 0, traffic share count is 1
Cisco891#telnet 10.10.10.1 /source-interface Lo1234
Trying 10.10.10.1 ... 
% Connection timed out; remote host not responding

Cisco891#

While I executed "telnet 10.10.10.1 /source-interface Lo1234" I tcpdumped traffic in IBM_server, but there were no packets captured. I find this little odd because there is an entry for 10.10.10.1 in the routing table and Loopback1234 interface has 10.10.10.2/24 configured to it so I don't see a reason why this shouldn't work.

I tried with "ping 10.10.10.1 source Lo1234" but got no replies. At the same time I tcpdumped traffic in IBM_server and received:

arp who-has 10.10.10.1 tell 192.168.1.202

..messages

In other words router was still using the IP address of the Gi0 interface not the address of Lo1234 interface.

Any other ideas?

Forsaken_GA

Well, if they're in the same vlan, why not make the 10.10.10.2 ip the primary on gi0, and 192.168.1.202 the secondary. Then your problem is solved without needing to do any trickery, unless you also need to make sure specific traffic is sourced from 192.168.1.202