DLSw question

[henrychwong]

Dear all,

Could anyone help me to clarify the following point on DLSw redundancy?

Is it true if DLSw redundancy (or recover) are transparent to user if the end stations lie on a token ring network ? On the other hand if the end stations lie on the ethernet LAN, the DLSw can re-established itself but it is not transparent to user. Can I make such a conclusion ?

thanks

[mbinzer]

Hi,

no, this statement is not true.

From an end systems perspective the recovery is always disruptive. No matter if you are on a tokenring or on a ethernet lan.

That means:

DLSw is about llc2 sessions at layer2. If your lan attached end system has a llc2 session with a cisco dlsw router and i.e. that router fails, the llc2 session with the end system will fail aswell.

After the end system has realized that the llc2 session is gone it cleans up its local connections and then tries to reestablish the llc2 connection. If another dlsw router is available, who can reach the requested remote host, than this connection will come up again. That means the end user sna session goes down and comes back up again.

The same is true if you are talking about dlsw+ ethernet redundancy.

There is more in the details/differences between ethernet and tokenring lan segments. I.e. on a tokenring you have a rif in each packet which can be used for loop control.

On ethernet you almost always have ethernet switches, where a cam table of a ethernet switch in any vlan for any mac address can only point to exactly one port on the switch.

If you have two dlsw routers connected that can reach the same remote host those two routers will both send frames with the same host mac address into the same switch on two different ports. This is where dlsw ethernet redundancy feature comes into play.

thanks...

Matthias

[henrychwong]

Thanks for your reply,

It means that there is no way for SNA traffic to be

recovered transparently as IP traffic does ?

thanks

[mbinzer]

Hi,

no, you can not transparently recover sna traffic like it is possible with ip traffic.

You can look into appn/snasw/hpr-ip. This allows for a mechanism to switch from one host to another one, backup, in case you loose a link without disrupting the actuall end user sna session. But if you want this to work transparently for a end system it means the end system must run the appropriate appn/hpr-ip stack.

If you run snasw/hpr-ip on a pair of routers for redundancy reasons on a lan segment than you can use

hpr-ip to have two connections from each router to the upstream host. If the primary link goes down you can switch to the secondary one without interrupting the end user session. But still if the router goes down and you have to switch to the secondary, backup, local router your llc2 sessions between this router and the end system still would go down and you loose the sna end user session. The same way i have already stated in the earlier reply.

The only way to do this really transparently for a end system would be to run appn/hpr-ip on the end system itself.

thanks...

Matthias

[henrychwong]

Hi,

You have mentioned that:

"DLSw is about llc2 sessions at layer2. If your lan attached end system has a llc2 session with a cisco dlsw router and i.e. that router fails, the llc2 session with the end system will fail aswell."

What if the end station has two links attached to the token-ring LAN (with same MAC addresses, possible ?)

with the cisco dlsw router ? Suppose one of the link of the end station fail and the router link still ok, then would the llc2 session be terminated ? Or it can

explore a new path to another healthy link without terminating the session ?

thanks

[mbinzer]

Hi,

what you describe would require quite some intelligence in the end system. I dont know of any end system which does something like this on a "normal" sna stack.

As far as i am concerned with the current implementation of dlsw. You loose the llc2 session in case of a failover. In that case you also loose the sna end user session and it needs to be reestablished over an alternative path. If there is one.

thanks...

Matthias

[henrychwong]

Hi,

it seems that appn/hpr-ip stack is the only solution

for SNA traffic, thank you very much and I will have a try on this.

thanks