In my environment I have a thousand of remote DLSw+ peers configured with circuit-count and costs. In a datacenter I have 8 routers to terminate DLSw+ connections. Working only with DLSw+ all remote peers establish the circuits in a balanced mode between peers with equal cost. This is working fine.
Recently I implement SNASw with HPR support (in a same router that was running DLSW+), and now the behavior of remote peers change.
Before, when the remote peer lost the 2 peers with cost 1, the circuits was established between other 2 peers with cost 2 in a balanced way. Now, when the peers with cost 1 are lost, all circuits are established over only one peer with cost 2. When the 2 peers with cost 1 return of failure, only one peer is used.
This is a normal behavior or my configuration have some problem ? Why with only DLSw+ all work fine ?
with the given information it is very difficult to determine if this is a config issue or normal behaviour.
If i understand the topology correct than your branch router is peering to 4 different host routers. Two with cost 1 and two with cost 2.
What you say is in the dlsw only case when you loose the two cost 1 peers the circuits get balanced over the remaining two cost 2 peers and in the dlsw/snasw case this balancing does not happen.
In the dlsw/snasw case how many entries in the reachability table to you still have after the two cost 1 peers are down? You should still see 2 entries for the given host mac.
If during the session establishment a circuit failure occurs dlsw on the branch router will remove the reachability for this particular peer and if there is still one other entrie left we dont reexplore we use the remaining entrie for the time beeing.
Do you have dlsw/snasw implemented on all 4 host peers you are peering too? If you implement dlsw/snasw on the same router that means that the host mac-addr is now configured on the vdlc port in the snasw configuration.
I think it might be the best for you to open a case with the TAC and have all the information gathered about your topology and configuration.
With that we are in a much better position to say if this behaviour you are seeing is normal or not.
The are other problems in tis environment due to configuration order of statement dslw peer... When this first configured peer fail, the router send the statement do the end of peers list configured, like a FIFO fashion. When this occour the reachability table have a strange behavior (in my opinion).
i did actually talk to the TAC people about your case. I think the real problem you have is the fact that our code does only cache up to 4 locations per mac address. You are doing this with up to 8 remote peers over which the same mac address is reachable. The limit of 4 cache entries is in the code since almost 7 years and this will not change at this point in time.
So we need to look if we can find any other way to accommodate your redundancy requirement in a way that works for you in your environment. The TAC guys are actively working on this.
In regards to the reordering of peers when a peer disconnects. This is normal behaviour too.
The configuration you see in a cisco router, the show run, is not a statical list we just display. It is always generated from the configuration state the router is realy in at the point you display it. In case of the dlsw peers we first process the connected peers and then the disconnected peers. This is how this is done since dlsw was introduced sometime 1995 .
I think the root cause that this causes some strange behaviour is again the fact that you have more than 4 peers up at a given time which can reach the same mac address.
I.e the TAC is currently testing the usage of backup peers. So that you have 4 peers configured with a backup peer each. If something happens to the host end router the backup peer for this host router then comes up and due to the configuration, icanreach mac ...., the cache is populated when the peer connects with an UNCONFIRMED reach entrie. That way you should always have 4 entries in the reach cache per host mac address and only 4 peers up and connected at any given time.
Please continue to work with the TAC towards a resolution of your issues. I am sure we will find a way to make it work so that your redundancy requirements are satisfied.
Introduction This article will help you understand the steps on how to
download the UCS licenses from the Cisco Systems website and then
installing it on the UCS. The redacted (blue lines) just covers up
certain numbers for privacy please do not take them...
Introduction This article will help you understand and educate the
customer on how to clear their "expired licenses"
(license-graceperiod-expired) from their UCS-M. If a customer just
purchased a license and needs a step by step guide on how to download
==================== VIC FNIC driver does not support Virtual Volumes (
second level LUN ID ) An enhancement request has been created to track
this feature - CSCux64473 UPDATE - 12-14-2016 We made some traction on
the enhancement request - The Fix is in t...