When applying SBC-B2B, as we know, the configuration dependence between SBC, interface SBC, traffic interface and vrf looks very like the figure below.
/\ / \ /SBC \ /.adj \ /.med-add\ /----------\ / intf SBC \ / Traffic intf \ /----------------\ / VRF \ /--------------------\ Fig 1. Pyramid of SBC-B2B config
VRF config is the foundation of other modules'.
Due to the defect CSCuf39344, when doing "no attach" then "attach" on an adjacency, the "VPN-ID" of this adjacency is updated.
As we know there may be two VRF Entries for a certain vrf in SBC B2B redundancy environment, one created locally and one synced from peer.
If an adjacency was configured on A-Box when it was ACTIVE, after switch-over, although calls through that adjacency are still OK, "no attach/attach" the adjacency on the new ACTIVE B-Box can cause the "VPN-ID" updated referring to the VRF Entry that locally configured on B-Box other than that synced from A-Box.
Incorrect config order can also lead to this problem:
If "no vrf definition <vrf-name>" was done before removing "media-address ipv4 <ip-addr> vrf <vrf-name>" and "vrf <vrf-name>" under adjacency, and later that vrf was readded and adjacency's "vrf <vrf-name>" was reconfigured.
Both method will cause adjacency's and media-address's "VPN-ID" different from each other.
The symptom is that:
1. calls are rejected with "503 Service Unavaliable" even if all configurations seem correct,
2. "media-address ipv4 <ip-addr> vrf <vrf-name>" may be displayed as "media-address ipv4 <ip-addr>" or "media-address ipv4 <ip-addr> vrf <some-other-vrf-name>" and cannot be removed.
This problem can be revealed with the following show commands:
ASR# show redundancy application group 1
ASR# show sbc <sbc-name> rg detail
Configure the following command to use the following show commands.
ASR(config)# service internal
ASR# show sbc <sbc-name> sbe mib vpssadjtable
ASR# show sbc <sbc-name> sbe mib mgmmediaaddresstable // never run this on Standby
We can see that adjacency refers to VRF Entry whose localid = 6 while media-address refers to 5.
If you found some media-address cannot be removed, then you can check the vrf table:
ASR# show vrf tableid
media-address refers to 5 which is the VRF Entry whose localid is 5.
However that VRF Entry's tableid is 0, not the value "0x00000003", or even worse there is no "vrf123" in the vrf table,
then you cannot remove that media-address record.
When configuring, please follow these steps (building pyramid from bottom up):
When removing, it should be done in the reverse order (tearing down pyramid from top down):
And make sure all configuring is done on the same box.
Or, we may meet problem.
For detailed steps, see below:
If it is not possible for you to always make configuration changes on the same box, then at least configure/remove a certain group of VRF, interface SBC, adjacency and media-address which all refer to that VRF on the same box.
Assume there are two ASRs: ASR-A and ASR-B and currently ASR-A is Active one.
ASR-A# show sbc <sbc-name> sbe mib vpssadjtable
ASR-A# show sbc <sbc-name> sbe mib mgmmediaaddresstable // never run this on Standby
ASR-A# show sbc <sbc-name> rg detail
ASR-B# show sbc <sbc-name> rg detail
Adjacency and media-address both refer to 5.
On ASR-A VRF Entry(localid=5)'s tableid is 0 but on ASR-B VRF Entry(localid=5)'s tableid is not 0.
Then the adjacency and media-address must be configured on ASR-B.
If you want to change or remove those configurations, you should first switch-over to ASR-B.
If we have already met the problem, and we can't reload the box immediately, have a try the workaround below, but with the notice that the workaround was developed in lab, no promise that always works.
The main goal of this workaround is to remove and reconfig vrf related CLIs where adjacency and media-address under that vrf do not serve calls (returning 503).
This workaround needs a switch-over, because without a switch-over, after removed one vrf, interface SBC cannot be reconfigured due to been locked by media-address which itself also cannot be removed.
First of all, make sure configurations on both active and standby sides are the same.