Back-To-Back cables for T1/E1/BRI/E&M

This is a simple reference to make back-to-back connections. Very useful in lab scenarios with voice gateways emulating the PSTN.

Thanks to Aashish for this :

T1/E1 crossover (for PRI and CAS back-to-back connection): 

RJ-45 ----- RJ-45
   1  -----  4
   2  -----  5
   4  -----  1
   5  -----  2

RJ-45 ----- DB-15
   1  -----   1
   2  -----   9
   4  -----   3
   5  -----  11

DB-15 ----- DB-15
   1  -----   3
   3  -----   1
   9  -----  11
  11  -----   9

ISDN BRI crossover (for BRI back-to-back connection): 

RJ-45 ----- RJ-45
   3  -----  4
   4  -----  3
   5  -----  6
   6  -----  5

Analog E&M (for analog E&M back-to-back connection):

RJ-45, 2-wire audio
   1  -----  8
   2  -----  7
   4  -----  5
   5  -----  4
   7  -----  2
   8  -----  1
         
RJ-45, 4-wire audio
   1  -----  8
   2  -----  7
   3  -----  5
   4  -----  6
   5  -----  3
   6  -----  4
   7  -----  2
   8  ------ 1

Analog FXS/FXO back-to-back connection:

RJ-11 ----- RJ-11
   2  -----   3
   3  -----   2

    RJ-11 connector
    ===============
         _____
        /    /|
       /4321/ |
      /____/  |
      ||||||  /
      |    | /
      |_--_|/
        \_\

    RJ-45 connector
    ===============
     _________
    /        /|
   /87654321/ |
  /________/  |
  ||||||||||  /
  |   __   | /
  |__|  |__|/
      \_\
                             

    DB-15 male connector
    ====================

pin 1 _______________ pin 8
     /. . . . . . . .\
     \ . . . . . . . /
pin 9 \_____________/ pin 15

Backup data with bcp

What I wanted was not to have more of two months of data online in my table. In order to do accomplish this task I decided to use Ms SQL Server's Bulk Copy Program (bcp).

Here's the MSDN page on bcp usage :
http://msdn.microsoft.com/en-us/library/ms162802.aspx

Then, using osql (MSDN) I'll clean up the table of the rows backupped.

In my table there's a field named dtRow which contains the timestamp as UTC.

I wrote this little batch :

@echo off

:CHECK_ARGUMENTS

if "%1"=="" goto PRINT_USAGE

if "%1"=="-?" goto PRINT_USAGE

:CHECK_ARG_DIRECTION

if "%1"=="in" goto RESTORE_AREA

if "%1"=="out" goto BACKUP_AREA

goto PRINT_USAGE

:BACKUP_AREA

:CHECK_ARG_DAYS

if %2==-d goto CHECK_ARG_DAYS_2

if not %1==-d goto PRINT_USAGE

:CHECK_ARG_DAYS_2

if not "%3"=="" goto CHECK_ARG_PATH

goto PRINT_USAGE

:CHECK_ARG_PATH

if not "%4"=="" goto CHECK_BCP

goto PRINT_USAGE

:CHECK_BCP

echo Looking for BCP....

IF EXIST %PROGRAMFILES%\Microsoft SQL Server\80\Tools\Binn\bcp.exe GOTO CHECK_BCP_OK ELSE GOTO CHECK_BCP_KO

:CHECK_BCP_OK

echo BCP exists.

goto CHECK_OSQL

:CHECK_BCP_KO

echo BCP does not exist!!.

goto EXITPROGRAM

:CHECK_OSQL

echo Looking for OSQL....

IF EXIST %PROGRAMFILES%\Microsoft SQL Server\80\Tools\Binn\osql.exe goto CHECK_OSQL_OK ELSE GOTO CHECK_OSQL_KO

:CHECK_OSQL_OK

echo OSQL exists.

goto BACKUP_DATA

:CHECK_OSQL_KO

echo OSQL does not exist!!.

goto EXITPROGRAM

:BACKUP_DATA

ECHO BACKUP DATA....

SET query="SELECT * FROM MyDB.dbo.MyTable WHERE dtRow > ((SELECT TOP 1 dtRow FROM MyDB.dbo.MyTable ORDER BY dtRow DESC) - 86400*%3)"

"%PROGRAMFILES%\Microsoft SQL Server\80\Tools\Binn\bcp.exe" %query% queryout %4 -N -U sa -P sa -S.\SQL2000

IF not %ERRORLEVEL%==0 goto ERROR_BACKUP

:DELETE_DATA

ECHO.

ECHO DELETING SAVED ROWS

SET query="DELETE FROM MyDB.dbo.MyTable WHERE dtRow > ((SELECT TOP 1 dtRow FROM MyDB.dbo.MyTable ORDER BY dtRow DESC) - 86400*%3)"

"%PROGRAMFILES%\Microsoft SQL Server\80\Tools\Binn\osql.exe" -S.\SQL2000 -U sa -P sa -d MyDB -Q %query%

ECHO Done.

goto EXITPROGRAM

:RESTORE_AREA

echo RESTORING DATA....

"%PROGRAMFILES%\Microsoft SQL Server\80\Tools\Binn\bcp.exe" MyDB.dbo.MyTable in %4 -N -U sa -P sa -S.\SQL2000

ECHO Done.

goto EXITPROGRAM

:PRINT_USAGE

ECHO Simple Backup Utility

ECHO Usage : obu {in | out} -d days path

ECHO days : Number of days to backup

ECHO starting from the last record.

ECHO path : Path of the backup file.

:ERROR_BACKUP

echo Error during backup phase. Aborting...

goto EXITPROGRAM

:EXITPROGRAM

Cisco and Nokia Dual Mode Part IV : SIP

Now time's to try the embedded SIP client on the Nokia devices.

As for reference I started with the Cisco manual (quite clear) :
http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cucm/admin/6_0_1/ccmcfg/b09sip3p.html

then I continued sniffing with wireshark the SIP registration (which failed), and at last I found the last useful clues on the Cisco NetPro Forum (thanks Ron!)

I decided to try with the Third Party Basic SIP device, however procedure for the Advanced  SIP device is almost the same.

So at last here's  the working configuration :

First configure the CUCM :

Get to System->Security Profile->Phone Security Profile and copy the Third-party SIP Device Basic - Standard SIP Non-Secure Profile and rename it (I used Third-party SIP Device Basic - LAB SIP Non-Secure Profile) and check the Enable Digest Authentication option. Leave unchanged the other settings.

Add the device as a Third-party SIP Device (Basic), set the phone's mac address (here's how to get it) and be sure to set this settings :
Device Security Profile to the security profile yuo've created previously
Digest User to your End User

 

 

Define the DN for your device.

In the End User configuration set the digest credentials (an alphanumeric password) and make the device association with the SIP phone.

Then it's time to configure the Nokia phone :

First get to Tools->Settings->SIP settings and create a new SIP profile :
Profile name :SIP
Service profile : IETF
Default access-point :<your access point>
Public username : sip:<dn>@><cucm ip>
Use compression : No
Registration : Always on
Use security : No

Proxy server
Proxy server address : sip:<cucm ip>
Realm : ccmsipline
Username : <End user userid>
Password : <Digest credentials>
Allow Loose routing : Yes
Transport type : UDP
Port : 5060

Registrar server
Registrar serv. addr. : sip:<cucm ip>
Realm : ccmsipline
Username : <End user userid>
Password : <Digest credentials>
Transport type : UDP
Port : 5060


Then get to Tools->Settings->Internet tel. settings and create a new SIP profile :
Name : Cisco SIP
SIP profile : SIP

Et voilà, if WLAN configuration is correct, you should see the phone register immediately.

Cisco and Nokia Dual Mode Part III : Mobility my way

After having configured the networking part of the problem here and then refined roaming here, time's to expose the Communications Manager side.

Targets were simple :

• People who have a dual-mode phone should always be reachable via IP if in WLAN coverage, regardless the caller dialed the office number or the mobile number.
• People who have a dual-mode phone should not be always reachable regardless the number dialed, but only if called on the cellular number, no automatic call diverting from the office number to the mobile number.
• The configuration should be as simple as possible and possibly cheap in terms of DLU
  

We decided not to implement the entire Cisco Mobility suite, but a subset of functions so saving DLUs and having the funtionality we needed.

Extension Mobility is enabled on all the IP Phones and users. Each desk phone has a dummy (not valid on the PSTN) line in a partition called Logout, from which can call only other desk phones, logged in users and emergency (there's a transformation pattern to make it exit on the PSTN).

Each user has a device profile with his personal line in a partition called Login (where all the logged in lines are).

Each dual-mode nokia mobile has two lines : the first shared with the device profile, the second belonging to a partition called Dual-Mode, unreacheable by anyone except from a particular CSS used by translation patterns.

This way behavior is :
People dialing the user's line while he is logged off from the desk phone and not under WLAN coverage (away) get fast busy or is redirected to VoiceMail.


People dialing the user's line while he is logged off from the desk phone but he is under WLAN coverage succeed in connecting since the line is active on the mobile through the Nokia IntelliSync Call Connect for Cisco.

People dialing the user's line while he is logged in and under WLAN coverage makes both the phones ring (shared line). Two notes on this : while in conversation on the mobile you can put the call on hold and then resume it from the desk phone (useful if you answer while away and the you reach your office), if you answer from the desk phone while both ringing, on the mobile you'll find a fake missed call.

People dialing the user's mobile number while he is under WLAN coverage will have their call translated to the "hidden" line on the mobile so using VoIP.

People dialing the user's mobile number while he is not under WLAN coverage will have their call translated to the "hidden" line on the mobile which have a call forward unregistered entry to the real mobile number.

Here's how this is configurated :

Partitions :
Logout : All the devices with no device profile logged in.
Login : All the lines of the device profiles
DualMode : All the "hidden" second lines on the nokia mobiles.

Desk Phone :
1000 in Logout partition.

Device Profile :
2000 in Login partition.


Mobile Phone :
2000 in Login partition.

7000 in DualMode partition.
Call Forward Unregistered on #3331234567 (mobile number)

Translation Pattern :
03331234567 becomes 7000
This one makes people looking for you on the mobile being translated on VoIP.

Route Pattern :
#.[3]! -> PreDot discard and prepend 0.
If you are not under WLAN coverage, the CFU to #3331234567 is routed to your real mobile. This is necessary because redirecting on the real number (03331234567) would meake the call enter a loop (the above mentioned translation pattern...)

Here's some self-explaining slides :

Cisco and Nokia Dual-Mode Part II : CCKM

After having made everything work with EAP-MSCHAPv2 (check out chapter one) I started the fine tuning session, thus finding some roaming issues.

In the Nokia IntelliSync Call Connect Datasheet (here) it is clear that the E-series are CCXv3 compatible.

On the Cisco side, this document says that CCKM with EAP-PEAP (MSCHAP) authentication is supported only with CCXv4 compatible devices.

Finally, the authentication provided by MS IAS on our infrastructure do not support LEAP (alternative to PEAP) so we need to move to a Cisco RADIUS authenticator i.e. ACS (at least in this phase, later we'll use the Cisco ACS 4 as a proxy vs. domain authentication).



Ok, we have to move from EAP-PEAP (MSCHAPv2) to EAP-LEAP protocol authenticating on Cisco ACS.

Here's the cisco doc on configuring the Cisco ACS for LEAP.

Once configured, we'll have to change both WLC and Phone's configuration.

The Wireless LAN Controller (from WCS):

Note on the last tab that DHCP Addr. Assignment Required should UNchecked otherwise you could ask for a new IP at each roaming session.

The Nokia Phone :

-Connection name : VoWLAN
-Databearer : Wireless WAN
-WLAN netw. name: TEST-ACS
-Network status: Hidden
-WLAN netw. mode: Infrastructure
-WLAN security mode: 802.1x (NOT WPA/WPA2)
-WLAN security settings :
--WPA mode: EAP
--EAP plug-in settings:
---EAP-LEAP (select only this, put in the higher position and disable all the others) :

---EAP-LEAP Configuration :
----User name: [Your radius user name]
----Prompt password: No
----Password: [Your radius password]


Now set this connection in the SCCP Profile and the registration to Always On (in chapter one you can find more info and links on this).

How can I see if CCKM is active ? Obviously user experience is useful, i.e., fast roaming is easily noticeable when speaking and walking togheter. However sometimes you could experience some holes in conversation without knowing if you have misconfigured CCKM or the WLAN coverage is not excellent, or both.

Debugging a client on the WLC will give you immediate evidence on this.

This Cisco doc is very useful to understand the entire process, however simply checking for a simple word in the debug output is simpler :

On the WLC issue the command "debug client [mac address of the Nokia device]" (here's how to see the nokia device's WLAN mac address).

Now start a conversation (ip obviously) with the nokia device and start walking so forcing a roaming. Each roaming makes the debug session display a huge amount of information about authentication, dot1x, etc (debugging...).
If CCKM is well configured, you should see in the roaming session output

CCKM: Mobile is using CCKM

and NOT see

Received EAPOL-key in REKEYNEGOTIATING state


If you normally experience correct fast roaming (CCKM) sessions and only sometimes you find key renegotiation (together with worse user experience) then you should check WLAN coverage in that areas, however CCKM should be well configured.

Hope this helps.

Cisco ACE and Private VLANs in Switch Mode

This one comes from the esigence to create a housing zone with a shared load balancer. The idea is to keep things as simple as possible providing isolation and all advanced load balancing feature.

So there will be only one vlan for one-armed servers and isolation will be provided by Private VLANs. However, being the ACE shared across the pvlans I had to add access lists to control traffic from one pvlan through another's vip.

Another element of simplicity in this design is the ACE module in switch-mode, this way providing a unique default gateway for all the servers (loadbalanced and not).

The network diagram :

The ACE configuration :

switch-mode

rserver host SERVER-10.1

ip address 10.0.10.1

inservice

rserver host SERVER-10.2

ip address 10.0.10.2

inservice

serverfarm host LAB-A_20.1:80

rserver SERVER-10.1 80

inservice

rserver SERVER-10.2 80

inservice

serverfarm host LAB-B_21.1:80

rserver SERVER-10.3 80

inservice

rserver SERVER-10.4 80

inservice

class-map match-any L4-SNAT
2 match source-address 1.0.10.0 255.255.255.0

class-map match-all L4-LAB-A_20.1:80

2 match virtual-address 10.0.20.1 tcp eq www

class-map match-all L4-LAB-B_21.1:80

2 match virtual-address 10.0.21.1 tcp eq www

policy-map type loadbalance first-match L7-LAB-A_20.1:80

class class-default

serverfarm LAB-A_20.1:80

policy-map type loadbalance first-match L7-LAB-B_21.1:80

class class-default

serverfarm LAB-B_21.1:80

policy-map multi-match L4-POLICYMAPMULTI
class L4-SNAT
nat dynamic 10 vlan 100

class L4-LAB-A_20.1:80

loadbalance vip inservice

loadbalance policy L7-LAB-A_20.1:80

loadbalance vip icmp-reply active

class L4-LAB-B_21.1:80

loadbalance vip inservice

loadbalance policy L7-LAB-B_21.1:80

loadbalance vip icmp-reply active

service-policy input L4-POLICYMAPMULTI

interface vlan 100

description SERVERSIDE

ip address 1.1.1.200 255.255.255.0

no normalization

no icmp-guard
nat-pool 10 10.0.100.1 10.0.100.15 netmask 255.255.255.224 pat

no shutdown

interface vlan 150

description FIREWALLSIDE

ip address 1.0.0.2 255.255.255.0

no normalization

no icmp-guard

no shutdown

ip route 0.0.0.0 0.0.0.0 1.0.0.1

The router's configuration :

svclc module 11 vlan-group 100

svclc vlan-group 100  10,20,100,150

vlan 10
  private-vlan community

vlan 20
  private-vlan community

vlan 100
  name SERVERSIDE

  private-vlan primary
  private-vlan association 10,20

vlan 150
 name P2P-C65-ACE

interface Vlan100
 ip vrf forwarding LAB
  private-vlan mapping 10,20
 
interface Vlan150
 ip vrf forwarding LAB
 ip address 10.0.0.1 255.255.255.240

As usual, on the ACE there's a nat pool to permit server to server load balancing, further information here and here.

"Horizontal" connections across the VLAN's broadcast are prevented by the private vlans' mechanism. However, a server belonging to the PVLAN A can connect to a VIP belonging (logically, as VIPs on the ACE are not PVLAN aware) to PVLAN B.

Being the ACE the default gateway, default behavior must be permit ip any any. Using access-lists and object-groups I created a matrix of negations between real servers on each pvlan versus all the VIPs of the other PVLANs :

object-group network GROUPA

host 10.0.10.1

host 10.0.10.2

object-group network GROUPB

host 10.0.10.3

host 10.0.10.4

object-group network VIPSGROUPA

host 10.0.20.1

object-group network VIPSGROUPB

host 10.0.20.2

access-list ACL01 line 7 extended deny ip object-group GROUPA object-group VIPSGROUPB

access-list ACL01 line 11 extended deny ip object-group GROUPA object-group VIPSGROUPB

access-list ACL01 line 15 extended permit ip any any

access-group input ACL01

Again, many thanks to Daniele and Marco   for support on the lab.

Asymmetric Server Normalization on Cisco ACE

Summertime, I've some time to spend in the lab to try some new scenarios, optimization or try something read on the release notes.
This scenario is mostly a proof of concept as in our DataCenter many applications use server to server load balancing and it requires a too messy configuration to make it work with ASN.
From the Cisco doc :

Asymmetric Server Normalization (ASN) allows the ACE to load balance an initial request from the client to a real server; however, the server directly responds to the client bypassing the ACE. This behavior allows the acceleration of server to client communications and is transparent to the client. When the ACE operates in ASN, it does not perform any network translation when receiving packets destined to the VIP address. Traffic from the client hits the VIP address and the ACE uses the address as the destination address but rewrites the destination MAC address to the address of the real server.

So the match is speed vs. capabilities.
Since the ACE do not control the entire flow (it sees only the packets vs. the VIP) most of the advanced load balancing features aren't usable.
However, in some cases, where speed is the most important thing and the application flow is quite simple it could be a good choice.
Here's my implementation :





On the ACE :

access-list ACL01 line 8 extended permit ip any any

! The probe should check for the health status of the loopback interface
! on the real server.
probe icmp ICMP
ip address 10.0.20.1
interval 5

rserver host SERVER-10.1
ip address 10.0.10.1
inservice
rserver host SERVER-10.2
ip address 10.0.10.2
inservice

! The transparent command prevents the ACE to make a destination NAT,
! sending the packet as is to the real server.
serverfarm host LAB_20.1:80
transparent
probe ICMP
rserver SERVER-10.1 80
inservice
rserver SERVER-10.2 80
inservice

class-map match-all L4-LAB_20.1:80
2 match virtual-address 10.0.20.1 tcp eq www

policy-map type loadbalance first-match L7-LAB_20.1:80
class class-default
serverfarm LAB_20.1:80
policy-map multi-match L4-POLICYMAPMULTI
class L4-LAB_20.1:80
loadbalance vip inservice
loadbalance policy L7-LAB_20.1:80
loadbalance vip icmp-reply active


service-policy input L4-POLICYMAPMULTI
access-group input ACL01

!The ACE is used as a bare load balancer, diasbling normalization (to make ASN work),
! and icmp-guard.
interface vlan 100
description SERVERSIDE
ip address 1.1.1.199 255.255.255.0
no normalization
no icmp-guard
no shutdown
interface vlan 150
description FIREWALLSIDE
ip address 1.0.0.2 255.255.255.0
no normalization
no icmp-guard
no shutdown

ip route 0.0.0.0 0.0.0.0 1.0.0.1

On the router :

ip route vrf LAB 10.0.20.0 255.255.255.0 10.0.0.2



This way everything works fine. Now it's time to make server to server load balancing work in this scenario.
What I wanted to work is a load balanced server that calls for its VIP being load balanced on itself or on another real server in the same area. Note that this scenario is different since here real server's are one-armed.

The choice to have a point-to-point vlan between the router and the ACE comes with the esigence to control traffic for some feature I needed described further. For simple ASN scenarios the ACE could easily have only one arm on the real servers' vlan (100).


Here's some observations I made :
1) Without any further configuration, server to server loadbalancing doesn't work as there's a loopback interface on the server with the VIP configured on it, you'll never get out of it.
2) You will need both source NAT and destination NAT to make it work.
3) You will have to make the ACE see all of the flow to make the NAT work.
4) You can't use ASN for server to server load balancing

I will not enumerate all of the tries I made to make it work (from which come the observations), here's my solution : double NAT (source and destination) on the router (6513 in this case) so that the ACE treats the connection as a normal external client request.




Here's the router's configuration :

interface Vlan100
ip vrf forwarding LAB
ip address 10.0.10.200 255.255.255.0
ip nat outside
!
interface Vlan150
ip vrf forwarding LAB
ip address 10.0.0.1 255.255.255.0
ip nat inside

ip nat inside source static 10.0.20.1 4.4.4.1
ip nat outside source static 10.0.10.1 6.6.6.1

ip route vrf LAB 10.0.20.0 255.255.255.0 10.0.0.2
ip route vrf LAB 4.4.4.0 255.255.255.0 10.0.0.2
ip route vrf LAB 6.6.6.1 255.255.255.255 10.0.10.199

The last route is a little tricky : as returning packets come from an outside zone to an inside one, packets need to be first routed and the natted. So you'll have to put a "fake" route versus an inside endpoint to make the packet then match the nat rule.

On the real servers you have a route to make all NATted request return by the ACE and not by the default gateway (router). These requests are easily identified by the source address (6.6.6.1).

Note that ASN and server to server load balancing with double NAT (source and destination) can be implemented both on the same box.

Thanks to Daniele and Marco for helping me in the lab.