We decided to implement the 1+1 cascaded topology with two SCEs 2020 and we realized that many strange things happen. The first and more important broblem was when the primary SCE recovers from a failure it immediately takes again the role of primary, but it does not have any data in its database with the result to lose all the existing quotas and information for the subscribers as we work in push mode with the API-SM.
For this reason we opened a case to cisco TAC and the answer is that is the normal behavior of the cascaded topology when the option in a case of failure is cutoff. Something that is nowhere documented and especially in the chapter of faiure scenarios in the SCE configuration. Also is strange to me that it is documented a feature that you have the chioce to put the SCE that comes from a failure to non operational mode, but it doesn't also work again in this configuration (cutoff in a failure).
The answer of the TAC is to use the bypass mode, but what can you do if this is a requirement of the customer? You have to redesign in order to be addressed with the customer needs (the MGSCP configuration it would be applicable, but it needs time and testing with the other components of the solution).
I don't know what is your opinion but i believe that is unacceptable answer for the reason that first the documentation was so poor for this kind of topology and second there was not only one feature that it doesn't work but two (the first was with the empty database when the primary recovers and the second was with the choice to becaome this SCE nonoperational when it recovers). I would accept that the first might be the way that this topology works, but the second is a configuration option that is not supported.
I documented my experience in this community in order to avoid engineers to use the 1+1 cascade topology of SCEs and to express my disappoitment in the way that Cisco handles this case.
Best Regards
