Find the answer to your Linux question:
Results 1 to 8 of 8
I have two networking interfaces on a Solaris host serving two different subnets. Only one of them is physically connected to the switch, but both of them are logically "UP" ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Jan 2009
    Posts
    4

    Question change routing metrics of locally connected networks


    I have two networking interfaces on a Solaris host serving two different subnets.
    Only one of them is physically connected to the switch, but both of them are logically "UP" (it's required this way).

    Let's assume iface bge0 got subnetwork 10.10.10.0 and iface bge1 got subnetwork 20.20.20.0 while bge0 is physically connected and bge1 is not.
    Unfortunately it's fact that I receive packets destined to network 20.20.20.0 (bge1) on bge0. The host tries to answer on bge1 because it's directly connected to this network. For this the answer is routed into nirvana.
    I know that this is some normal behaviour but I need the host to send the answer packet for 20.20.20.0 out on another interface than the one which serves the network locally. I need it to be sent out iface bge0 where the original request was received, but not out bge1.


    The background for this strange environment is raised up to two facts:
    - the application only serves incoming packets if the sender is in a locally connected network
    - VPN connection between two hosts in the same subnet

    application A configuration:
    - bge0 - 10.10.10.10 physically up, logically up
    - bge1 - 20.20.20.20 physically down, logically up

    application B configuration:
    - bge0 - 10.10.10.11 physically down, logically up
    - bge1 - 20.20.20.21 physically up, logically up

    app "A" sends packets via VPN to app "B"
    src: 10.10.10.10 --> dst: 20.20.20.21
    if bge0 is logically down on app "B", the application will refuse to process the packets
    --> bge0 on app "B" is logically up raising the problem that app "B" will send the answer out bge0 (locally connected)
    --> packet will never arrive at the other end of the VPN tunnel because routing configuration can only be established via bge1


    Is it possible to change the routing metrics of locally connected networks (Flag "U" in routing table) to some higher than a statically inserted route to enforce routing the packets out another interface than the one which is locally connected to the network?
    Is it possible to force using the default route for some network instead of using iface of the locally connected network?
    Any other possibility to solve this problem without kernel hacking ?

  2. #2
    Just Joined!
    Join Date
    Jan 2009
    Location
    holland
    Posts
    12
    another logical newbie reply from me, if u have to set the metrics manually u can maby first try to set the subnets and ip"s manually because u go deeper into the settings.. but this is one of the things for experts, i would specially advise backups before u do anything.. good luck!

    p.s. vpn client is one way and vpn server is two way, its an option..

    vpn; clientvpnwareto------->>------server [one way]

    vpn; clientvpnserverto-------<<->>------>server [two way] the question is does vpn server software exists.. beats me NetMAX VPN Server Suite

  3. #3
    Just Joined!
    Join Date
    Jan 2009
    Posts
    4
    Thanks for your reply.

    I already thought about establishing some Client-to-Site VPN connection to suppress the VPN routing problem but thinking about it more intensive I come to the same conclusion that at least one host is not able to route the packets out the right interface.
    Even Client-to-Site VPN is not ment to have the same ip address range at client and server site. The server is pushing the right routes to the client to connect to all needed networks.

    So working on the VPN will not make sense in my opinion.
    If I wouldn't have the routing problem on the hosts it would be fine

  4. #4
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,677
    What does your routing tables look like on both servers?
    Also what does the interface configuration look like on both servers?

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

  5. #5
    Just Joined!
    Join Date
    Jan 2009
    Posts
    4
    GER - bge1 is physically connected, bge0 is not
    ---------------------------------------------------------

    bash-2.03# ifconfig -a
    lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
    inet 127.0.0.1 netmask ff000000
    bge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
    inet xxx.xxx.139.215 netmask fffffff0 broadcast xxx.xxx.139.223
    ether 0:3:ba:8d:d3:55
    bge1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
    inet yyy.yyy.139.55 netmask fffffff0 broadcast yyy.yyy.139.63
    ether 0:3:ba:8d:d3:56

    bash-2.03# netstat -rn
    Routing Table: IPv4
    Destination Gateway Flags Ref Use Interface
    -------------------- -------------------- ----- ----- ------ ---------
    yyy.yyy.139.48 yyy.yyy.139.55 U 1 559762 bge1
    xxx.xxx.139.208 xxx.xxx.139.215 U 1 460368 bge0
    224.0.0.0 xxx.xxx.139.215 U 1 0 bge0
    default yyy.yyy.139.49 UG 1 329
    127.0.0.1 127.0.0.1 UH 1 0 lo0


    USA - bge0 is physically connected, bge1 is not
    ---------------------------------------------------------

    bash-2.03# ifconfig -a
    lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
    inet 127.0.0.1 netmask ff000000
    bge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
    inet xxx.xxx.139.210 netmask fffffff0 broadcast xxx.xxx.139.223
    ether 0:3:ba:90:7c:9
    bge1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
    inet yyy.yyy.139.50 netmask fffffff0 broadcast yyy.yyy.139.63
    ether 0:3:ba:90:7c:a

    bash-2.03# netstat -rn
    Routing Table: IPv4
    Destination Gateway Flags Ref Use Interface
    -------------------- -------------------- ----- ----- ------ ---------
    xxx.xxx.139.208 xxx.xxx.139.210 U 14018039 bge0
    yyy.yyy.139.48 yyy.yyy.139.50 U 1 9 bge1
    224.0.0.0 xxx.xxx.139.210 U 1 0 bge0
    default xxx.xxx.139.209 UG 1 105551
    127.0.0.1 127.0.0.1 UH 15333673863 lo0




    USA host <==> Routing Switch <==> VPN-GW -----
    ----- VPN-GW <==> Routing Switch <==> GER host

  6. #6
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,677
    Why don't you make sub-interfaces?

    For example;

    GER:
    bge0 = x.x.x.x
    bge0.1= y.y.y.y

    USA:
    bge0 = y.y.y.y
    bge0.1 = x.x.x.x

    Then they both will use the same physical port with different ip addresses.
    Also are you populating the routing table by hand? They look a mess.
    You should let the system do this.

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

  7. #7
    Linux Guru
    Join Date
    Nov 2007
    Posts
    1,756
    A) Why are you asking a question about routing on a Solaris machine on a Linux forum? Wouldn't there be better assistance on BigAdmin? (Solaris' TCP stack is not the same as Linux - Project FireEngine was Sun's response to cleaning up the stack to improve performance against Linux.)

    B) The table is completely normal for a Solaris system, but the entry causing your issue is the 20.20.20.20 line. This is simply an entry that says if a packet's destination is the 20.X network, use bge1, because it's attached to that network. I don't know the full consequences, but you can try and delete this from the routing table. If that were gone, the stack would be forced to send the packet to its default router address.

    Any other possibility to solve this problem without kernel hacking?
    Being a Solaris kernel, you won't be doing much kernel hacking.

    Why don't you make sub-interfaces?
    If the packets actually need to go somewhere, this won't work. Because the bge0.1 interface is on the 20.X network, it will try and ARP for the MAC of the destination machine. When that fails, it will report destination unreachable - the packets will not be sent to any gateway.

  8. #8
    Just Joined!
    Join Date
    Jan 2009
    Posts
    4

    Thumbs up

    I never thought about deleting a route of a locally attached interface but its really working.

    I did the following:
    route delete -net xxx.xxx.139.208/28 xxx.xxx.139.215
    The other way round on the other host...

    Afterwards the hosts are able to ping themselves via the VPN even if both interfaces on both hosts are up, because the routing tables are missing the local network route and for this are sending the request out the default gateway interface.

    Thanks for all your help

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •