[Solaris] preferred interface voor uitgaand verkeer

[Gertjan]

Korte probleembeschrijving: ik wil forceren dat Solaris een bepaalde netwerkinterface liever vindt dan andere interfaces.

Setup: een machine met een zestal netwerkaansluitingen: twee onboard Broadcom-poorten (bnx0 en bnx1, bnx1 niet in gebruik) en 4 Intel-poorten (e1000g0-3). De Intel-poorten zijn per twee getrunked middels LACP in aggr0 en aggr1. Over aggr0 en aggr1 heen ligt een IPMP-interface, ipmp0.

De machine wordt ingezet als fileserver en draait op Nexenta (OpenSolaris + Debian-userland). De bedoeling is dat al het NFS-verkeer over de IPMP-interface gaat. Die is getrunked voor meer bandbreedte en is verbonden met twee switches voor high availability. De bnx0 interface is alleen bedoeld voor administratieve doeleinden.

Het probleem is dat bnx0 toch gebruikt wordt als uitgaande interface, terwijl alle clients verbinding maken met IP-adressen op de IPMP-interface. Bijvoorbeeld:

code:

[e-mail] ~ # netstat -I bnx0 -i 1
    input   bnx0      output       input  (Total)    output
packets errs  packets errs  colls  packets errs  packets errs  colls 
25      0     6864    0     0      21055   0     14690   0     0     
21      0     6894    0     0      18946   0     14018   0     0     
17      0     7130    0     0      18821   0     17747   0     0     
30      0     5236    0     0      20773   0     15894   0     0     
21      0     6726    0     0      23765   0     20962   0     0     
18      0     5915    0     0      29022   0     23077   0     0     
31      0     9288    0     0      23635   0     22321   0     0     
23      0     7381    0     0      17115   0     16538   0     0     
15      0     4650    0     0      24028   0     19622   0     0

code:

[e-mail] ~ # netstat -I ipmp0 -i 1
    input   ipmp0     output       input  (Total)    output
packets errs  packets errs  colls  packets errs  packets errs  colls 
11987   0     4581    0     0      24004   0     17526   0     0     
15910   0     9351    0     0      31843   0     25957   0     0     
16343   0     6492    0     0      32711   0     23227   0     0     
13541   0     7935    0     0      27098   0     23284   0     0     
16862   0     12977   0     0      33746   0     32160   0     0     
15509   0     10913   0     0      31037   0     28181   0     0     
16112   0     10301   0     0      32255   0     27561   0     0     
15274   0     7856    0     0      30611   0     25285   0     0     
17114   0     7687    0     0      34297   0     26050   0     0     
18909   0     11094   0     0      37859   0     31454   0     0

Op zich werken de routes naar de clients toe volgens mij wel goed:

code:

[e-mail] ~ # route get web9.c1.internal
   route to: web9.c1.internal
destination: 10.1.0.0
       mask: 255.255.0.0
  interface: ipmp0
      flags: <UP,DONE>
 recvpipe  sendpipe  ssthresh    rtt,ms rttvar,ms  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0

Ik heb de reden dat het uitgaande verkeer deels over bnx0 gegooid wordt volgens mij wel gevonden: de arp-table heeft entries voor een boel hosts op bnx0:

code:

[e-mail] ~ # arp -a
Net to Media Table: IPv4
Device   IP Address               Mask      Flags      Phys Addr
------ -------------------- --------------- -------- ---------------
ipmp0  service1.c1.internal 255.255.255.255          00:14:22:7c:b1:4c
bnx0   service1.c1.internal 255.255.255.255          00:14:22:7c:b1:4c
ipmp0  web7.c1.internal     255.255.255.255          00:1d:09:24:5e:ea
bnx0   web4.c1.internal     255.255.255.255          00:1a:a0:15:47:67
bnx0   web5.c1.internal     255.255.255.255          00:1a:a0:17:02:7f
bnx0   web8.c1.internal     255.255.255.255          00:1d:09:24:5e:ed
bnx0   web9.c1.internal     255.255.255.255          00:1d:09:24:5e:f6
ipmp0  web10.c1.internal    255.255.255.255          00:1d:09:24:64:ef
ipmp0  dns1.c1.internal     255.255.255.255          00:1e:c9:2e:a8:e5
bnx0   dns1.c1.internal     255.255.255.255          00:1e:c9:2e:a8:e5
bnx0   web11.c1.internal    255.255.255.255          00:1e:c9:2e:a8:dc

Sommige hosts staan zowel op ipmp0 als op bnx0 in de arp-table. Als ik ze echter probeer te verwijderen wordt alleen de entry op ipmp0 verwijderd, die op aggr0 blijft erin staan. Hosts die alleen een entry op aggr0 hebben kunnen niet verwijderd worden:

code:

[e-mail] ~ # arp -d web4.c1.internal
web4.c1.internal (10.1.1.40) -- no entry

De vragen: is dit gedrag normaal? Hoe kan ik ervoor zorgen dat al het verkeer over ipmp0 gaat, tenzij er verbonden wordt met een IP-adres op bnx0? Waarom kan ik de entries op bnx0 niet verwijderen uit de arp-table?

[Gertjan]

Extra informatie: ifconfig (relevante entries), routingtable

code:

[e-mail] ~ # ifconfig -a
lo0: [..]
ipmp0: flags=8001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,IPMP> mtu 1500 index 2
        inet 10.1.2.29 netmask ffff0000 broadcast 10.1.255.255
        groupname ipmp0
ipmp0:1: [..]
aggr0: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 3
        inet 10.1.2.27 netmask ffff0000 broadcast 10.1.255.255
        groupname ipmp0
        ether 0:15:17:f1:76:ee 
aggr1: flags=39040803<UP,BROADCAST,MULTICAST,DEPRECATED,IPv4,NOFAILOVER,FAILED,STANDBY> mtu 1500 index 4
        inet 10.1.2.28 netmask ffff0000 broadcast 10.1.255.255
        groupname ipmp0
        ether 0:15:17:f1:75:a 
bnx0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 1496 index 5
        inet 10.1.2.36 netmask ffff0000 broadcast 10.1.255.255
        ether 5c:f3:fc:9:5a:24 
bnx1: [..]
lo0: [..]

code:

[e-mail] ~ # netstat -rn

Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface 
-------------------- -------------------- ----- ----- ---------- --------- 
default              10.1.1.1             UG        4     250896 bnx0      
10.1.0.0             10.1.2.28            U         3    2342818 aggr1     
10.1.0.0             10.1.2.27            U         3    2529197 aggr0     
10.1.0.0             10.1.2.31            U        34 1578896157 ipmp0     
10.1.0.0             10.1.2.29            U        10 3766929985 ipmp0     
10.1.0.0             10.1.2.36            U        21 1006326042 bnx0      
127.0.0.1            127.0.0.1            UH       17    4938680 lo0

[CAPSLOCK2000]

Kun je ook de output van

netstat -rnv

posten. Zonder netmasks is de routetabel een stuk minder nuttig.

Je default-route loopt via bnx0, en je hebt ook een route naar 10.1.0.0 via bnx0 lopen (net als via aggr en ipmp). Dat lijkt te conflicteren (met de juiste netmasks kan het wel, maar die mis ik dus).

[Kees]

Je zou eventueel arp kunnen uitzetten op bnx0 zodat hij er niet op reageert. Maar het zou zo maar kunnen dat je dan die interface helemaal niet meer kan bereiken van buitenaf. Hoe je het kan uitzetten: 'man ifconfig' '/arp'.

[Gertjan]

CAPSLOCK2000 schreef op donderdag 12 mei 2011 @ 15:57:
Kun je ook de output van

netstat -rnv

posten. Zonder netmasks is de routetabel een stuk minder nuttig.

Zeker:

code:

IRE Table: IPv4
  Destination             Mask           Gateway          Device  MTU  Ref Flg  Out  In/Fwd 
-------------------- --------------- -------------------- ------ ----- --- --- ----- ------ 
default              0.0.0.0         10.1.1.1             bnx0    1496   3 UG    5422      0 
10.1.0.0             255.255.0.0     10.1.2.25            aggr1   1500   3 U   228249      0 
10.1.0.0             255.255.0.0     10.1.2.24            aggr0   1500   3 U   228248      0 
10.1.0.0             255.255.0.0     10.1.2.30            ipmp0   1500  28 U   500165348   5432 
10.1.0.0             255.255.0.0     10.1.2.26            ipmp0   1500   8 U   64025768      0 
10.1.0.0             255.255.0.0     10.1.2.35            bnx0    1496  12 U   105654381      0 
127.0.0.1            255.255.255.255 127.0.0.1            lo0     8232  17 UH  147665 147665

Je default-route loopt via bnx0, en je hebt ook een route naar 10.1.0.0 via bnx0 lopen (net als via aggr en ipmp). Dat lijkt te conflicteren (met de juiste netmasks kan het wel, maar die mis ik dus).

Het leek mij inderdaad ook te conflicteren, maar ik snapte eerlijk gezegd niet precies hoe het anders ingesteld zou moeten worden. De netmasks uit de output van route lijken het ook niet echt beter te maken .

FYI: bnx0 wordt via DHCP geconfigureerd, aggr0, aggr1 en ipmp0 worden statisch geconfigureerd:

code:

[e-mail] ~ # cat /etc/hostname.aggr0
group ipmp0 -failover 10.1.2.27/16 up
[e-mail] ~ # cat /etc/hostname.aggr1
group ipmp0 -failover 10.1.2.28/16 standby up
[e-mail] ~ # cat /etc/hostname.ipmp0 
ipmp group ipmp0 10.1.2.29/16 up
addif 10.1.2.31/16 up

Kees schreef op donderdag 12 mei 2011 @ 21:21:
Je zou eventueel arp kunnen uitzetten op bnx0 zodat hij er niet op reageert. Maar het zou zo maar kunnen dat je dan die interface helemaal niet meer kan bereiken van buitenaf. Hoe je het kan uitzetten: 'man ifconfig' '/arp'.

Dat is niet echt een optie, bnx0 moet voor administratieve doeleinden wel bereikbaar blijven .

[JMW761]

Gertjan schreef op donderdag 12 mei 2011 @ 12:58:

De machine wordt ingezet als fileserver en draait op Nexenta (OpenSolaris + Debian-userland). De bedoeling is dat al het NFS-verkeer over de IPMP-interface gaat. Die is getrunked voor meer bandbreedte en is verbonden met twee switches voor high availability. De bnx0 interface is alleen bedoeld voor administratieve doeleinden.

Als high-availability belangrijk is, dan geldt dat neem ik aan ook voor die administratieve doeleinden...

punt is dat dit niet op te lossen is als je in het zelfde netwerk-segment wil blijven met de interface voor administratieve doeleinden.

oplossing is dus segmenteren in verschillende subnets en NFS-verkeer over de trunk laten lopen en de admin via het andere segment (en dus de andere poort)

[H!GHGuY]

Kun je de metric niet aanpassen?
ifconfig <bnx0|aggr1|aggr0> metric X
Dan zou alle verkeer bij voorkeur de link met laagste metric moeten nemen.
Mogelijk moet je ook met "ip addr change" aan de slag om je routing table aan te passen.

Mocht dit niet werken, dan kun je ook met source-based routing werken. Hierbij creeer je verschillende routing tables en laat je de kernel de juiste routing table kiezen afhankelijk van het source-adres van het outgoing packet.

Dan moet je moet
ip rule ...
en
ip route ...
aan de slag.

[Voor 57% gewijzigd door H!GHGuY op 14-05-2011 22:20]

[Gertjan]

@H!GHGuY: Ja, dat zou inderdaad nog kunnen, maar is wel een vrij omslachtige oplossing voor wat ik wil bereiken. Ik denk dat ik maar met de oplossing van JMW761 ga: de betreffende interface in een ander netwerksegment/vlan plaatsen.

Dank voor jullie adviezen!