Mirroring session table

Deb,

 

 

Have you managed to get any more info on this? I have managed to get session mirroring to work to a degree, however when i use the statement:

 

session add uie KEY DATA TIMOUT

 

The only info that is mirrored to the other unit is:

 

VIP POOL KEY 0 (DATA missing)(this is seen in a tcpdump of mirror traffic between units)

 

 

Example:

 

 

session add uie [IP::local_addr] "hello" 20

 

 

Trace of mirror traffic:

 

 

........t0.....o

 

0x0060 7574 626f 756e 642d 7564 702d 5254 5350 utbound-udp-RTSP

 

0x0070 2d54 4553 5400 4645 4133 322d 4669 7265 -TEST.FEA32-Fire

 

0x0080 7761 6c6c 0031 302e 3232 352e 3830 2e32 wall.10.225.80.2

 

 

(hello" missing)

 

 

Any help would be much appreciated!

 

Regards,

 

 

Evan.

 

 

Correct me if I am wrong, or perhaps not understanding the question, but session mirroring is doable via the virtual IP itself (e.g. session mirroring). We put this in place for specific applications, and forced it over an out-of-band network channel, tcpdump's yield a ton of information, case in point, we have a webservices VIP that displays all of the real time SOAP data flowing through the out-of-band channel. I don't fancy using UIE for this function when it's built into the VIP as an advanced config item.

 

 

Am I missing something?

Hi,

 

 

Session mirroring will mirror all transport information required to allow the standby unit to carry on where the old active unit left off i.e src/dst tcp ports etc. Persistence mirroring is also important and is configured as an additional, seperate option. It is used to tell the standby unit where to send the packets after a failover has occured. We are trying to use this fuinctionality to mirror a product ID across to the standby unit - as far as i am aware, there may be no way to mirror iRule specific info across to the standby...

 

 

Evan.

Glad you found this out, this is exactly what I was saying in my earlier post. You need to use session mirroring on the VIP which will replicate all session information to the standby unit, we do this for select projects where required. I have seen data entered from the primary replicated to the standby, simply did a tcpdump on the standby.

 

 

One thing I would highly caution everyone on is, make sure you setup a secondary administrative VLAN and assign your failover IP's to it, which will force session mirroring over that select VLAN. I found this out the hardway when we had a particular application receiving dual database posts with session mirroring enabled, we had to force everything through an out-of-band VLAN (essentially setup a crossover cable between the active and standby, setup a VLAN and assigned IP's, then forced all synchronization and failover traffic to it) solved everything, and works great.

 

 

Course it's not 100%, nothing is, if the data from a client isn't replicated in time when the primary goes down, there is a potential for loss of data, but the risk is small.