LINK AGGREGATION IN SOLARIS

Link aggregation is the way of binding two or more interfaces and refer under one name so that the speed of the network interfaces can be maximized .

In solaris 10 we use dladm tool to create link aggregation . You can find these details for creating link aggregation in this post .

Before creating link aggregation let review what are required for that . We need just a server with additional NIC cards. Make sure that you are in console if you are doing this on the nic used for public IP.

root@solaris1>dladm show-dev
e1000g0 link: up speed: 1000 Mbps duplex: full
e1000g1 link: up speed: 1000 Mbps duplex: full
e1000g2 link: up speed: 1000 Mbps duplex: full

Unplumb the interfaces before you use for link aggregation , otherwise it might give the error ,like the interface is in use . (Here I am using e1000g1 and e1000g2 for link aggregation)

Below is the dladm command used with create -aggr subcommand to create link aggregation of e1000g1 and e1000g2 .

root@solaris1>dladm create-aggr -d e1000g1 -d e1000g2 1

option -d specifies the device name and argument 1 is the first instance .(It creates the link aggr1).

Now as specified using argument 1 generally called a key value will create link aggr1 .

root@solaris1>dladm show-aggr
key: 1 (0x0001) policy: L4 address: 0:c:29:ad:75:ca (auto)
device address speed duplex link state
e1000g1 0:c:29:ad:75:ca 0 Mbps half unknown standby
e1000g2 80:ac:ce:0:80:fe 0 Mbps half unknown standby


dladm with subcommand show-aggr will show the key value , policy used and mac address used for created aggr1 . Still the state for interfaces is in standby because aggr1 is not plumbed yet . So, plumb the aggr1 device now .

root@solaris1>ifconfig aggr1 plumb
root@solaris1>ifconfig -a
lo0: flags=2001000849 mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
e1000g0: flags=1000843 mtu 1500 index 2
inet xxx.xxx.xx.20 netmask ffffff00 broadcast 1xx.xxx.xx.255
ether 0:c:29:ad:75:c0
aggr1: flags=1000842 mtu 1500 index 3
inet 0.0.0.0 netmask 0
ether 0:c:29:ad:75:ca

assign IP address to aggr1 and now the aggr1 is ready with IP and accepts/send IP packets .

root@solaris1>dladm show-aggr
key: 1 (0x0001) policy: L4 address: 0:c:29:ad:75:ca (auto)
device address speed duplex link state
e1000g1 0:c:29:ad:75:ca 1000 Mbps full up attached
e1000g2 80:ac:ce:0:80:fe 1000 Mbps full up attached

Below is the statistics shown for the links used in aggregation .

root@solaris1>dladm show-aggr -s
key: 1 ipackets rbytes opackets obytes %ipkts %opkts
Total 8 512 8 512
e1000g1 8 512 0 0 100.0 0.0
e1000g2 0 0 8 512 0.0 100.0

Importing the destroyed DG in VxVM.

There are few chances of human mistakes , might be of low impact or high impact . You might experienced using VxVM , where we use Disk groups to build the logical hierarchy to create volumes for accessing the disk .

If accidentally , that important disk got destroyed by mistake . Uffff how to get it back now .. .. .
Dont worry , in VxVM even though if DG is destroyed , if those disks are not used of any other purpose (for creating other DG) . We can get that back .

Want the trick to get worked ? then you might require some info regarding that destroyed DG . Dont worry , just required the DG ID that is shows under vxdg list , similar to the below one.

root@solaris1>vxdg list
NAME STATE ID
testdg enabled,cds 1294599911.10.solaris1

root@solaris1>vxdg destroy testdg
root@solaris1>vxdisk list
DEVICE TYPE DISK GROUP STATUS
c1t0d0s2 auto:none - - online invalid
c1t1d0s2 auto:SVM - - SVM
c1t2d0s2 auto:cdsdisk - - online
root@solaris1>vxdg list
NAME STATE ID

Uffff .. I destroyed my DG . Yeap , I have the required info to get it back ....... My DG ID 1294599911.10.solaris1

Use the vxdg import with the DG ID and that will get your DG back imported and enabled .

root@solaris1>vxdg import 1294599911.10.solaris1
root@solaris1>vxdg list
NAME STATE ID
testdg enabled,cds 1294599911.10.solaris1


root@solaris1>vxdisk list
DEVICE TYPE DISK GROUP STATUS
c1t0d0s2 auto:none - - online invalid
c1t1d0s2 auto:SVM - - SVM
c1t2d0s2 auto:cdsdisk disk01 testdg online


That got saved . Helpful hint doesnt it ..

Password less login through Secure Shell

Secure Shell(SSH) is the secure way of accessing the servers . Before ssh Telnet was mostly used for log in , but the disadvantage of using telnet comes with the way it transfers the information/data across network.
Using telnet , makes the data transfer across the network with out any encryption . All the info transferred is in plain text format. Risk comes ,if someone captures the data packets over network and will be able to clearly see any data transferred like passwords .

To eliminate this risk , use ssh for login which in turn encrypts all the data that is transferred over network .

One more advantage of using ssh is , we can make use of public key authentication which allows login without requiring any password to be entered . This setup of key authentication between two servers will be presented in this post . (This is possible because ssh first looks for key authentication setup , if no key setup or private key or if public key doesnt matches private key , then ssh will prompt for password ).

Initially we consider to have two servers solaris1 and solaris2 which has sshd daemon /services active on them . (In this we setup the login from solaris1 to solaris2

Firstly we need to have a two keys for each servers one is public key and other private key . This can be generated with the built in ssh tool ssh-keygen command .

solaris2#ssh-keygent -t dsa

Generating public/private dsa key pair.
Enter file in which to save the key (//.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in //.ssh/id_dsa.
Your public key has been saved in //.ssh/id_dsa.pub.
The key fingerprint is:
c2:3e:db:15:cf:f5:b4:fa:88:03:50:95:a1:c5:34:df root@solaris2

-t : option specify the algorithm to be used for key generation (possible values will be dsa or rsa).

It will prompt for the file name and location to be used , we can specify the one or by default it will be in $HOME/.ssh/ directory location . Need to enter passphrase (if needs to be password less login then enter empty passphrase , here we give the empty passphrase so that it wont prompt for passphrase while login).

Once the passphrase is validated , a public key will be created in the same location where private key was located with the name convention as privatekeyname.pub (we have here id_dsa.pub).

root@solaris2>cd /.ssh
root@solaris2>ls
id_dsa id_dsa.pub known_hosts
root@solaris2>cat id_dsa.pub
ssh-dss AAAAB3NzaC1kc3MAAACBAMh9QAZfSlQIPMIl9iMHFWM0UzLoSs24DtojCqKZj8WVhoy6TfpuausJ06WzAfvq2RD2tnd69iYSx/AUbxZGpZIp3buMN0ybTBbqo4YiyG8h8YHMuSvxQ+ryGpmD+VhLpgJKhZKdKcO0VerH4s0m8nUn2lwstobtFuIa2ks6u/ZXAAAAFQDhCS445aGzUj9QmqQjOap/F5KzmQAAAIByAYIKYWyy1ioy8s+zmIAmSEGRyR2jA2CqBMgU5j2sGqWQV0ZCRANLQ1hBFLHOSzPJVHlB0XYACSqUVRw6fXW+6ROirjraSN143pgZNltWU8UJnFZPBv246UiY0/OcVCBoDqIqz2HsfBP0MtoA0VV21qVcMQWsSUPJpK8GUVLb7QAAAIBwYsfVNtBTat8CRKFqloPEQQ6BlDvtRGF2t+pCYEC9YbFKYE63z998q1pu2eDmvbiWTJ3+ZTMQ8CDp77DY3KLaXAgzEbh9pGaQdFORZCli2E2x7E3S9Z68SJBzP4JtM5ADTJiNVbT+iji45dEIvkFeox8u1fPSYAyXYdJ4L9uy7g== root@solaris1

Copy the content of this id_dsa.pub key .

This id_dsa.pub is the key that needs to be distributed across the servers from where we need a password less login .

To distribute the pub key we need to create a file with filename authorized_keys2 in all the servers and keep the copied content of id_dsa.pub in that file and then save the file .

root@solaris1>cat authorized_keys2
ssh-dss AAAAB3NzaC1kc3MAAACBAMh9QAZfSlQIPMIl9iMHFWM0UzLoSs24DtojCqKZj8WVhoy6TfpuausJ06WzAfvq2RD2tnd69iYSx/AUbxZGpZIp3buMN0ybTBbqo4YiyG8h8YHMuSvxQ+ryGpmD+VhLpgJKhZKdKcO0VerH4s0m8nUn2lwstobtFuIa2ks6u/ZXAAAAFQDhCS445aGzUj9QmqQjOap/F5KzmQAAAIByAYIKYWyy1ioy8s+zmIAmSEGRyR2jA2CqBMgU5j2sGqWQV0ZCRANLQ1hBFLHOSzPJVHlB0XYACSqUVRw6fXW+6ROirjraSN143pgZNltWU8UJnFZPBv246UiY0/OcVCBoDqIqz2HsfBP0MtoA0VV21qVcMQWsSUPJpK8GUVLb7QAAAIBwYsfVNtBTat8CRKFqloPEQQ6BlDvtRGF2t+pCYEC9YbFKYE63z998q1pu2eDmvbiWTJ3+ZTMQ8CDp77DY3KLaXAgzEbh9pGaQdFORZCli2E2x7E3S9Z68SJBzP4JtM5ADTJiNVbT+iji45dEIvkFeox8u1fPSYAyXYdJ4L9uy7g== root@solaris2


Now try to login to the server with the user id for which the ssh keys were setup . (here we did that for root user ).

root@solaris1>ssh root@solaris2
Last login: Mon Jan 10 00:21:19 2011 from solaris1
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
root@solaris2>

Now no password will be requested while login .

Identfying a Global zone from Local zone

There are direct command , through which we can know the local zones , if we are in global zone.
(zoneadm list -cv ) . But to know the global zone from local zone , we dont have a direct zone command .

For that to identify a global zone , use arp command from local zone (arp is the command that shows up the arp table of network address which are mapped with mac address)

arp command with flag with -a option displays the list of IP addresses mapped to MAC address .
From the arp -a command the IP/Server which has the flag of SPLA is the global zone .(There will be one more entry for SPLA Flag , which is for the local zone we are querying from or other sister local zone for the same global zone ) .

Check Resources state in VCS

In day to day working on veritas cluster , most informative step is to check the status of all the resources in a service group . This post shows that importance of hares command , which gives more info regarding the resources with single line command .

To check the state of all the resources in the service group on a particular node .

hares -display -attribute State -group SGNAME | grep servername

the above command fetches the info with the attribute value . We can modify the command to know any attribute value ,like Type of the resource (Type is also one of the attribute like State ) .

You can find all the attributes with the hares -display resourcename .