netstat clarification

[iman_1]

My netstat output is as follows

# netstat -in
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
lan900:1 1500 none none 0 0 0 0 0
lan900:3 1500 XX.XX.XXX.0 XX.XX.XXX.55 559128 0 1315 0 0
lan900:2 1500 none none 0 0 0 0 0
lan0 1500 YYY.YYY.Y.0 YYY.YYY.Y.199 2954319390 1 742417125 0 0
lo0 4136 127.0.0.0 127.0.0.1 109733376 0 109733378 0 0
lan900:4 1500 XX.XX.XXX.0 XX.XX.XXX.58 186619 0 0 0 0
lan900 1500 XX.XX.XXX.0 XX.XX.XXX.54 24983905 0 24970996 0 0

Can somebody explain me which physical address does the lan900:1 , lan900:2 and lan900:3, lan900:4 translate to in ioscan -fnClan ?

We have Port aggregation done on lan900, but others are confusing.

Ciao

[Ganesan R]

Hi Iman,

lan900:1 , lan900:2, lan900:3, lan900:4 all are not physical addresses.

These are all virtual interfaces bound to lan900. It could be cluster package ip's or OS virtual ip's

There is only one physcial interface that is lan900 which is aggregated. If you want to see the physical interfaces aggregated to lan900 use #lanscan -q command.

[iman_1]

Ganesan,

My lanscan output is as below

lanscan -q
9
10
11
12
14
15
16
1
2
3
4
0
900 13 17
901
902
903
904


I know Port aggrgation is done on 900 and lan13 and lan17 are connected to it.

Where do I get the details of lan900:1 , lan900:2 and lan900:3, lan900:4 ?

Ciao.

[Ganesan R]

Hi Iman,

As I told, these are all just virtual interfaces bound to lan900.

Consider this example:
You have lan0 interface. You can configure more than one ip on this interface. First ip will be assigned to lan0. Next ip will create virtual interface lan0:1 and ip will be assigned to this interface.

Both lan0 and lan0:1 is pointing to same physical device lan0. Hope this clear you.

>>>Where do I get the details of lan900:1 , lan900:2 and lan900:3, lan900:4 ?<<<

What details do you want from these virtaul interfaces?

[Ivan Krastev]

Hello iman,

For lan900:1,2,3 ... look into /sbin/init.d/ directory.

Grep for ifconfig in the startup scripts.


regards,
ivan

[smatador]

Hi,
With APA, you have few configuration file, take a look at your configuration file
/etc/rc.config.d/hp_apa* and /etc/lanmon/lanconfig.ascii for understanding if your are on loadbalancing

nwmgr -c lan900

[Mel Burslan]

If you are in some sort of cluster configuration on this server, these lan900:X addresses may be getting fired up by different cluster service packages to be used as their service addresses.

When it comes to physicality, your lan900 is the only interface all your traffic is passing through. When you map it into the cables, you are using lan13 and lan17. There are two possibilities of how you use them:

1. in a high throughput configuration, lets say lan13 and lan17 are 100BaseT ports. You adjoin the two and make a bigger capacity (virtually 200 MBit/sec) network pipe.

2. in a fail-over configuration, in which you traffic is going through either one of lan13 or lan17 but not both at the same time. In case of the primary interface in this pair fails, then the other take ove the whole traffic making it highly available.

In most cases, network administrators balk at the method 1 as it requires them to do some funky routing arrangement on their end. Hence most people use APA as a redundancy solution with method 2 described above. You can look at /etc/rc.config.d/hp_apaportconf and see how this configuration is done. if you see something similar to this:

HP_APAPORT_INTERFACE_NAME[2]=lan13
HP_APAPORT_CONFIG_MODE[2]=LAN_MONITOR

it means you are in failover mode and all your APA interface traffic is actually flowing through one of either lan13 or lan17

anything denoted with a column followed by a number after lan900 is nothing more than a virtual IP address of the same interface, so physically they are bound by the same APA rules.

Hope this helps.

[rick jones]

A minor terminology nit. Interfaces of the form:

lanN:M

should probably be called "logical" interfaces. They exist only in the mind of the transport (IP and above) and not as distinct interfaces in the space reported by lanscan, which will restrict itself to "lanN"

I'd avoid calling them virtual interfaces as that might confuse with either APA or VLANs.