OCOM Not Getting Traffic Data From SBC in Overlapping Subnets

Asset ID:	1-75-2015381.1
Update Date:	2018-01-18
Keywords:

Solution Type Troubleshooting Sure

Solution 2015381.1 : OCOM Not Getting Traffic Data From SBC in Overlapping Subnets

Applies to:

Acme Packet 4500 - Version S-Cx6.4.0 and later
Acme Packet 3820
Oracle Communications Session Monitor - Version 3.3.90 to 3.3.90 [Release 3.0]
Information in this document applies to any platform.

Purpose

Troubleshoot communication issues between OCOM and SBC in the case of potential overlapping subnets

Troubleshooting Steps

Goal

Establish connection between OCOM and SBC successfully, so SBC sends traffic properly to OCOM

Solution

Make sure you have followed the directives in <Document 1679579.1>

If you still face issues with establishing proper communication between the SBC and OCOM, a possible reason for this not to work properly could be that there are multiple media interfaces configured on the SBC, that belong to the same subnet. When configuring the comm-monitor module, make sure that you use the first media interface in the network interface order, as SBC will use that by default when attempting to connect to OCOM. Check the example right below, to get a better understanding, where SBC is configured with the following media interfaces

> show running-config network-interface

...

network-interface
name M10
sub-port-id 0
description
hostname
ip-address 192.168.26.176
pri-utility-addr 192.168.26.178
sec-utility-addr 192.168.26.179
netmask 255.255.255.0
gateway 192.168.26.254
sec-gateway
gw-heartbeat
   state enabled
   heartbeat 10
   retry-count 3
   retry-timeout 3
   health-score 31
dns-ip-primary
dns-ip-backup1
dns-ip-backup2
dns-domain
dns-timeout 11
signaling-mtu 0
hip-ip-list 192.168.26.176
ftp-address
icmp-address 192.168.26.176
snmp-address
telnet-address
ssh-address
last-modified-by admin@192.168.123.168
last-modified-date 2014-09-11 14:49:10
network-interface
name M11
sub-port-id 0
description
hostname
ip-address 192.168.26.77
pri-utility-addr 192.168.26.75
sec-utility-addr 192.168.26.76
netmask 255.255.255.0
gateway 192.168.26.254
sec-gateway
gw-heartbeat
   state enabled
   heartbeat 10
   retry-count 3
   retry-timeout 3
   health-score 33
dns-ip-primary
dns-ip-backup1
dns-ip-backup2
dns-domain
dns-timeout 11
signaling-mtu 0
hip-ip-list 192.168.26.77
ftp-address
icmp-address 192.168.26.77
snmp-address
telnet-address
ssh-address
last-modified-by admin@192.168.55.206
last-modified-date 2015-04-11 01:36:35

...

Note that both interfaces M10 and M11 belong to the 192.168.26.0/24 subnet. Note also that the show interfaces command displayed the following output

> show interfaces

...

sp (unit number 1):
Flags: (0x68043) UP BROADCAST MULTICAST ARP RUNNING INET_UP
  Type: ETHERNET_CSMACD
  inet: 192.168.26.176
  Broadcast address: 192.168.26.255
  Netmask 0xffffff00 Subnetmask 0xffffff00
  Ethernet address is 00:08:25:20:56:6e
  Metric is 0
  Maximum Transfer Unit size is 1500
  114321399 octets received
  1897196 octets sent
  1237643 unicast packets received
  21500 unicast packets sent
  0 non-unicast packets received
  0 non-unicast packets sent
  0 incoming packets discarded
  0 outgoing packets discarded
  0 incoming errors
  0 outgoing errors
  3 unknown protos
  0 collisions; 0 dropped
  0 output queue drops

sp (unit number 2):
Flags: (0x68043) UP BROADCAST MULTICAST ARP RUNNING INET_UP
  Type: ETHERNET_CSMACD
  inet: 192.168.26.77
  Broadcast address: 192.168.26.255
  Netmask 0xffffff00 Subnetmask 0xffffff00
  Ethernet address is 00:08:25:20:56:6f
  Metric is 0
  Maximum Transfer Unit size is 1500
  13064 octets received
  0 octets sent
  114 unicast packets received
  0 unicast packets sent
  0 non-unicast packets received
  0 non-unicast packets sent
  0 incoming packets discarded
  0 outgoing packets discarded
  0 incoming errors
  0 outgoing errors
  3 unknown protos
  0 collisions; 0 dropped
  0 output queue drops

...

From the above one can view that the following correlation applies

M10 <=> sp1

M11 <=> sp2

In the meanwhile, OCOM target is at 192.168.26.220, so the corresponding configuration would look like the following

> show running-config system-config

system-config
...

comm-monitor
      state enabled
      sbc-grp-id 0
      tls-profile
      qos-enable enabled
      monitor-collector
          address 192.168.26.220
          port 4739
          network-interface M11:0

...

In the above configuration notice that SBC is configured to send traffic to OCOM through interface M11 (sp2). Nevertheless, if one executes the show arp command, will view the following output

> show arp

LINK LEVEL ARP TABLE
destination gateway flags Refcnt Use Interface
--------------------------------------------------------------------------
...
192.168.26.100 38:ea:a7:14:15:1c 33686533 0 0 sp1
192.168.26.220 2c:44:fd:95:38:d4 33686533 0 20708 sp1
192.168.26.254 00:26:51:2b:f1:c8 33686533 3 0 sp1

...

As you can see from above, although comm-monitor is configured to use M11 (sp2) to access OCOM, SBC will attempt to establish the connection over M10 (sp1). This creates a conflict in SBC, and connection to OCOM is never established. Thus, one needs to configure the first media interface (M10) to establish connection to OCOM, for the configuration to work.

# configure terminal
(configure)# system
(system)# system-config
(system-config)# select
(system-config)# comm-monitor
(comm-monitor)# select
(comm-monitor)# monitor-collector
(monitor-collector)# select
address:
1: 192.168.26.220

selection: 1

(monitor-collector)# network-interface M10:0
(monitor-collector)# done
monitor-collector
  address 192.168.26.220
  port 4739
  network-interface M10:0
(monitor-collector)# exit
(comm-monitor)# done
comm-monitor
  state enabled
  qos-enable enabled
  sbc-grp-id 0
  tls-profile
  monitor-collector
      address 192.168.26.220
      port 4739
      network-interface M10:0
(system-config)# done
system-config
...
  comm-monitor
      state enabled
      qos-enable enabled
      sbc-grp-id 0
      tls-profile
      monitor-collector
          address 192.168.26.220
          port 4739
          network-interface M10:0
  last-modified-by admin@10.165.125.106
  last-modified-date 2015-06-04 09:52:50
**(system)# exit
**(configure)# exit
**# save-config
checking configuration
Save-Config received, processing.
waiting for request to finish
Request to 'SAVE-CONFIG' has Finished,
Save complete
Currently active and saved configurations do not match!
To sync & activate, run 'activate-config' or 'reboot activate'.
*# activate-config
Activate-Config received, processing.
waiting for request to finish
Request to 'ACTIVATE-CONFIG' has Finished,
Activate Complete
#

In case the interface change does not work immediately, do attempt to disable/re-enable the comm-monitor module in order to setup the connection to OCOM from scratch:

// disabling comm-monitor

# configure terminal
(configure)# system
(system)# system-config
(system-config)# select
(system-config)# comm-monitor
(comm-monitor)# select
(comm-monitor)# state disabled
(comm-monitor)# done
comm-monitor
state disabled
  qos-enable enabled
  sbc-grp-id 0
  tls-profile
  monitor-collector
      address 192.168.26.220
      port 4739
      network-interface M10:0
(system-config)# done
system-config
...
  comm-monitor
      state disabled
      qos-enable enabled
      sbc-grp-id 0
      tls-profile
      monitor-collector
          address 192.168.26.220
          port 4739
          network-interface M10:0
**(system)# exit
**(configure)# exit
**# save-config
checking configuration
Save-Config received, processing.
waiting for request to finish
Request to 'SAVE-CONFIG' has Finished,
Save complete
Currently active and saved configurations do not match!
To sync & activate, run 'activate-config' or 'reboot activate'.
*# activate-config
Activate-Config received, processing.
waiting for request to finish
Request to 'ACTIVATE-CONFIG' has Finished,
Activate Complete
#

// re-enabling comm-monitor

# configure terminal
(configure)# system
(system)# system-config
(system-config)# select
(system-config)# comm-monitor
(comm-monitor)# select
(comm-monitor)# state enabled
(comm-monitor)# done
comm-monitor
  state enabled
  qos-enable enabled
  sbc-grp-id 0
  tls-profile
  monitor-collector
      address 192.168.26.220
      port 4739
      network-interface M10:0
(system-config)# done
system-config
...
  comm-monitor
      state enabled
      qos-enable enabled
      sbc-grp-id 0
      tls-profile
      monitor-collector
          address 192.168.26.220
          port 4739
          network-interface M10:0
**(system)# exit
**(configure)# exit
**# save-config
checking configuration
Save-Config received, processing.
waiting for request to finish
Request to 'SAVE-CONFIG' has Finished,
Save complete
Currently active and saved configurations do not match!
To sync & activate, run 'activate-config' or 'reboot activate'.
*# activate-config
Activate-Config received, processing.
waiting for request to finish
Request to 'ACTIVATE-CONFIG' has Finished,
Activate Complete
#

Note also that the above limitation would apply, even if the two interfaces were configured with different VLAN tags (sub-port-id). In the case we had the following:

> show running-config network-interface

...

network-interface
name M10
sub-port-id 99
description
hostname
ip-address 192.168.26.176

...

network-interface
name M11
sub-port-id 101
description
hostname
ip-address 192.168.26.77
...

and the comm-monitor configuration would be to use M11:101 for connecting to OCSM, the connection would not work. That would be because the arp and routing table entries with respect to the specific subnet would precede any VLAN tag consideration. Thus, one would face the exact same issue as described above, where connection would actually try to go over M10, which would be the wrong route.

References

Created from <SR 3-10320854961>

Applies to:

Acme Packet 4500
1-914CU

References

<BUG:21024910> - SBC NOT ESTABLISHING CONNECTION TOWARDS COMM-MONITOR/MONITOR-COLLECTOR
<NOTE:1674673.1> - What Log Files are Required when Opening a Service Request for Palladion / Oracle Communications Session Monitor
<NOTE:1679579.1> - How to set your SBC to work as a probe for Oracle Communications Session Monitor (Palladion)

Attachments

This solution has no attachment