IPv6/4 classification for Crossbow
Networking virtualization project crossbow provide users L3,L4 FLOW classification capabilities. Users can keep their traffic isolated vs.
client's data traffic, voice traffic. Isolation of services is very important
for virtualization, when there are no separate instances of OS (execution environments).
As part of Crossbow's virtualization and resource management work, I have been involved working on IPv6 and IPv4 virtualization with crossbow, IPv6 packets should get classified separate over IPv4 packets with flowadm defined policy.
Thus, new crossbow bits allow following attributes along with transport+port -
* transport - icmpv6
* local_ip[/prefix_len] - Local IPv4/IPv6 address
* remote_ip[/prefix_len] - Remote IPv4/IPv6 address
* ip_version - 4 or 6
This set can classify IP address/netmask based flows and transport+port based flows as well as combination of local_ip,remote_ip,local_ip+remote_ip+transport,
local_ip+remote_ip+transport+local_port+remote_port also these policies are direction sensitive.
Further, multiple attributes support for flows also involvs "position aware placement of flows in flow table such as most specific flows should be ahead
of less specific flows, irrespective of the order in which they were added"
as well as varying combination of different set of attributes should work
as well as single attribute based flows should work. i.e.
#flowadm add-flow -a ip_version=4 IP4 -l bge0 -b
Usage of such functionalities are-
----------------------------------
TCP traffic or UDP traffic between 2 subnets/networks could be prioritized or classified separate from each other.
privileged nodes could have separate flow policies for their host-addresses along with type (TCP/UDP/...etc ) traffic and port, peer to peer networks may benefit.
Traffic (say TCP/UDP) from a remote network to a particular VM instance or Virtualized exclusive IP-zone could be classified, B/W controlled separate over generic traffic policies.
Set of IP addresses could be specified to classify and prioritize say Forwarding traffic.
example
--------
bash-3.2# flowadm add-flow -a local_ip=fe80::20a:e4ff:fe26:6eca,remote_ip=fe80::/10,transport=TCP ip3 -l bge0
# flowadm add-flow -a local_ip=1.1.1.1,remote_ip=2.2.2.2,transport=TCP,local_port=8080,remote_port=4040 tcp3 -l e1000g0
[Read More]Posted at 12:42PM May 28, 2008 by ddeepti in General |
Live upgrade with solaris
1)
During the initial install create alternate partition or else leave enough disk space for
alternate partition, boot environment,
I created 2 partitions 1 for initial install and second for secondary.
2)
I have had
/dev/dsk/c1t0d0s0 mounted as /
and
/dev/dsk/c1t0d0s4 mounted as /second_root
slices.
df -hk output will show the available clices and also the mountpoints.
3)
#umount /second_root
comment out corresponding entry from /etc/vfstab
4)
now execute command-
lucreate -c "snv_87: -m/:/dev/dsk/c1t0d0s4:ufs -n "snv_87_2"
5)
I do LUpgrade from a install cd.
now execute command -
luupgrade -u -n snv_87_2 -s /cdrom/sol_x11_86
6)
remove DVD
7)
#init 6
8)
after reboot into either partition you will see -
# lustatus
Boot Environment Is Active Active Can Copy
Name Complete Now On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
snv_87 yes no no yes -
snv_87_2 yes yes yes no -
9)
you can do lumount the other partition.
#lumount snv_87
/.alt.snv_87
10)
you can cd to /.alt.snv_87 change contents and or bfu into this alternate bootable
partition such as -
# bfu /.../nightly /.alt.snv_87
#acr
#reboot
Posted at 05:05PM May 06, 2008 by ddeepti in General |