Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Feature Overview

The SBC SWe Cloud cloud currently supports maximum two packet (PKT) ports such as PKT0 and PKT1. If these PKT ports are virtual interfaces (ports from virtual Standard Switch (vSS) or virtual Distributed Switch (vDS) on VMware ESXi or ports from OVS on a KVM platform), port redundancy is supported through NIC teaming or bonding feature, which exists on respective hypervisor vSwitches.

However, if these PKT ports are on SR-IOV interfaces, currently there is no way to support the port redundancy is not supported for PKT interfaces as since hypervisor is by-passed in such NIC configuration. The SBC SWe Cloud is enhanced to To support port redundancy on SR-IOV interfaces, this feature is enhanced on SBC SWe cloud platform, which works based on the ICMP/ARP probing mechanism. This mechanism requires four PKT ports (SR-IOV VFs) configured on a SBC SWe Cloud instance, where each of these SR-IOV VFs may come from different physical NICs for better handling of connectivity failures due to physical NIC or physical link connected towards different physical switches.

The PKT ports are automatically configured in active-standby mode to provide port redundancy on active SBC SWe Cloud instance.   The PKT ports connected in standby SBC SWe Cloud instance remains in standby mode. The ICMPv4/v6 probing mechanism is used on active PKT ports, while ARP ACD/ICMPv6 NUD mechanism is used on standby ports.

...


Note

The port redundancy feature is enabled only in Distributed SBC on an Openstack platform and SBC 7000 models. 

Architecture

The following figure shows the SBC SWe Cloud cloud redundancy model from a port-centric view using a secondary packet port for each primary packet port. A standby instance SWe with its own primary and secondary packet ports is also depicted in this figure. On standby instanceSWe, all packet ports remains as standby. For example, in this diagram, the active SWe ports are PKT0_P and PKT1_S ports.

Caption
 
0Figure

...

1Port Redundancy Architecture
Image Removed

Image Added


Terminology:

  • Primary port: The PKT port that attempts to become active on an active SWe node. The packet ports on the SBC SWe (PKT0_P, PKT1_P) are considered as primary ports.

Secondary port:

    The PKT port is designated as an alternative for a specific on-board primary port. The SBC SWe contains one secondary port for each primary port.
    • Active port: The PKT port that is currently selected for use (For example, signaling, media); either a primary or a secondary port on an active SWe node.

  •  
    • Note
      The port in the active state does not necessarily imply it is "up".
    • Local standby port: A standby PKT port on an active SWe node provides redundancy protection to the currently active port.

    • Standby port: A collective term for a local standby PKT port on an active SWe node or any packet port on an standby SWe node. Standby ports provides protection for active PKT ports.
    • Enabled or Disabled ports: The PKT port may be administratively enabled or disabled. A PKT port that is disabled cannot be an active port.

  •  
    • Note
      The PKT port's role (Primary/Secondary) is independent of the port's state (Active/Standby).
  •  
    • Note
      For SBC SWe
  • cloud platform
    • Cloud, the Out of Service (OOS) sonusSbxNrsIpInterfaceOOSNotification alarm for Interface Group is generated only for logical ports pkt0 and pkt1. This alarm is not generated when physical ports (pkt0_p, pkt0_s, pkt1_p and pkt1_s) are down.

Link Detection Support

The SBC SWe Cloud supports link detection on standby and active ethernet ports to determine the health of standby port before initiating a switchover/failover. The intent is to allow simple connectivity checking to test the ability of 

Spacevars
0product
to send/receive ethernet frames, connectivity to the adjacent switch/router, and the ability of the switches/router to do basic layer 2 receiving/forwarding/sending.

The following probing mechanisms are available on the 

Spacevars
0product
platforms:

Caption
0Table
1SBC Probing Mechanism Types
 
Probing MechanismSBC PlatformsAffected PortsPurpose
ICMP pingSBC SWeActive ports only

Checks two-way connectivity between 

Spacevars
0product
port and the configured destination (adjacent router) by sending ICMP Ping messages at configured intervals to the destination.

...

Note
When destination IP address is configured in a Link Monitor, ICMP ping is enabled. By setting the destination IP address to NULL (0.0.0.0), the ICMP ping is disabled. 
ARP ACD/ICMPv6 NUD*SBC SWe Cloud Platform

Standby ports only

Performs active checking of two-way traffic through at least the local Ethernet interface, the cable, and the adjacent layer 2 switching function.

Checks are accomplished using ARP (for IPv4) or Neighbor Discovery (for IPv6) mechanisms to probe an arbitrary, operator-specified target IP address on a local IP subnet, typically an address of a router (Gateway IP address). Depending on the address family (IPv4/IPv6) of the gateway IP address configured, either ARP ACD or ICMPv6 NUD probing messages are sent in such a way that explicit assignments of IP addresses to the standby ports are not required.

Checks the link state between 

Spacevars
0product
port and the adjacent router.

*  Address Resolution Protocol - Address Conflict Detection / Internet Control  Message Protocol Version 6 – Neighbor Unreachability Detection

ARP ACD/ICMPv6 NUD Methods for Standby Ports

IPv4 ARP ACD

If the destination address configured is an IPv4 address, then IPv4 probing is initiated by sending an ARP Probe requests and listening for the responses.

ARP request probes are sent with:

  • Sender IP address of 0.0.0.0.  The use of 0.0.0.0 is compatible with rfc 5227 on IPv4 Address Conflict Detection. This is convenient to use on standby ports since IP addresses are not assigned for standby ports.
  • Sender hardware address containing the current local MAC address assigned to the sending port.
  • Target IP address containing the configured target IP address to be probed.
  • Target hardware address containing all zeros. The ARP request is sent on the LAN using L2 broadcast.

The target can be expected to respond with an ARP Response using L2 unicast. 

IPv6 ICMPv6 NUD

If the destination address configured is an IPv6 address, then IPv6 probing would be initiated using Neighbor Unreachability Detection mechanism (RFC 4861 section 7). This is based on Neighbor Solicitation and Neighbor Advertisement ICMPv6 messages.

Because these are IP packets, the 

Spacevars
0product
needs IP addresses to send/receive them. The 
Spacevars
0product
uses auto-generated link local IPv6 address from the current local MAC address.

Neighbor Solicitation messages are sent with:

  • IP source address containing auto-generated link local IP address
  • IP destination address containing configured target IP address
  • ICMP layer target address containing configured target IP address
  • ICMP layer source link layer address containing PKT port MAC address

The Neighbor Solicitation message is sent on the LAN via L2 unicast to the system with the target IP address.

The target can be expected to respond with a Neighbor Advertisement using L2 unicast. Received messages are validated per RFC 4861 section 7.1.2: Check that the S bit = 1 (solicited) and that the target address = our configured target IP address.

Note

The SBC SWe Cloud may reduce the call accept rate when it syncs from the active to the standby CE under full load causing some calls to get rejected with a 503 message even though the applied load is below the specified maximum call rate. This condition clears once the synchronization to the standby completes. Additionally, some calls may get rejected with a 503 message when synchronization occurs while the applied load is near the maximum specified.

Pagebreak