DTMF on VoIP

When carrying them on the SIP Network you could probably see the following methods of conveying these tones across:

1.- Inband:

DTMF are sent using the same RTP stream  as the media is using, and can be heard by carries in a session. Compression Codecs such as G.729 and G.723 may make tones unintelligible so it really works on better codecs like G.711

http://quequero.org/DTMF_decoding#DTMF_decoding_a_naive_approach

2.- RCF 2833:

(config)#dial-peer voice 100 voip

(config-dial-peer)#dtmf-relay ?

rtp-nte RTP Named Telephone Event RFC 2833

this is an out of band method that takes DTMF out of the RTP Stream, this means that the DTMF codes works even if the voice stream is compressed. This packets travelling out of band of RTP, hold events that can be understood by UA and regenerated, DTMF-related named events within the  telephone-event payload format.  http://www.ietf.org/rfc/rfc2833.txt

(config-dial-peer)#voice-class sip dtmf-relay force rtp-nte

A hidden command that forces the  “voice-class sip dtmf-relay force rtp-nte” DTMF relay negotiation to rtp-nte and It’s only necessary if the other side doesn’t advertise rtp-nte.

output from deb ccsip media

000373: Dec  4 02:11:45.727: //55/18EBD6C48068/SIP/Media/sipSPIUpdCallWithSdpInfo:
Stream type             : voice+dtmf
Media line              : 1
State                   : STREAM_ADDING (2)
Callid                  : -1
Negotiated Codec        : g711ulaw, bytes :160
Nego. Codec payload     : 0 (tx), 0 (rx)
Negotiated DTMF relay   : rtp-nte
Negotiated NTE payload  : 101 (tx), 101 (rx)
Negotiated CN payload   : 0
Media Srce Addr/Port    : 10.0.1.5:0
Media Dest Addr/Port    : 192.168.21.31:20424
000374: Dec  4 02:11:45.727: //55/18EBD6C48068/SIP/Info/sipSPIHandleInviteMedia:
Negotiated Codec       : g711ulaw, bytes :160
Preferred Codec        : g711ulaw, bytes :160
Preferred  DTMF relay 1 : 6
Preferred  DTMF relay 2 : 0
Negotiated DTMF relay   : 6
Preferred and Negotiated NTE payloads: 101 101
Preferred and Negotiated NSE payloads: 100 100
Preferred and Negotiated Modem Relay: 0 0
Preferred and Negotiated Modem Relay GwXid: 1 0

Image

output from debug voip rtp session named-event will show digit 5 sent in 7 packets –

Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:04 00 00  <Snd>>>
Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:04 00 00  <Snd>>>
Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:04 00 00  <Snd>>>
Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:04 01 90  <Snd>>>
Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:84 03 20  <Snd>>>
Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:84 03 20  <Snd>>>
Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:84 03 20  <Snd>>>

The first packet says that it is the start of a new NTE digit because it does not have the endbit set .

The second and third packets are repeats of the first packet for redundancy.

The fourth packet is a refresh packet with a duration of 50ms (0x0190 = 400 samples * 1sec / 8000 samples).

The fifth packet is the endbit packet (84) with a duration of 100ms (0x0320 = 800 samples * 1sec / 8000 samples).

The sixth and seventh packets are redundant packets for packet five.

in this RFC more events are defined, like for example: Fax related tones, Standard subscriber and Country Specific line tones and Trunk Events

Image(1)

This http://www.rfc-editor.org/rfc/rfc4733.txt supersedes RFC  2833, since  devices do not have to support every tone and event there is, they just simply advertise what they DO support when setting up a a connection

3.- SIP INFO: http://www.faqs.org/rfcs/rfc2976.html

This method is used to carry session control information along the SIP Signaling path during an existing session. SIP info can carry the digits you type without changing the characteristics of the SIP Session.

(config)#dial-peer voice 100 voip
(config-dial-peer)#session proto sip
(config-dial-peer)#dtmf-relay ?
cisco-rtp          Cisco Proprietary RTP
h245-alphanumeric  DTMF Relay via H245 Alphanumeric IE
h245-signal        DTMF Relay via H245 Signal IE
rtp-nte            RTP Named Telephone Event RFC 2833
sip-kpml           DTMF Relay via KPML over SIP SUBCRIBE/NOTIFY
sip-notify         DTMF Relay via SIP NOTIFY messages

you can not configure Cisco SIP-INFO to generate requests for DTMF tones, since this method is Considered Harmful based on http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00

The SIP INFO Method for DTMF Tone Generation feature is always enabled, and is invoked when a SIP INFO message is received with DTMF relay content. This feature is related to the SIP NOTIFY-Basec Out-of-Band DTMF Relay Support feature, which provides the ability for an application to be notified about DTMF events using SIP NOTIFY messages. Together, the two features provide a mechanism to both send and receive DTMF digits along the signaling path.

A Networker Blog

Advertisements

Quick Glance @ SDP

SDP is intended to be used for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.

http://www.ietf.org/rfc/rfc2327.txt

v=  (protocol version)
o=  (owner/creator and session identifier).
s=  (session name)
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information – not required if included in all media)
b=* (bandwidth information)
One or more time descriptions (see below)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
Zero or more media descriptions (see below)

Time description
t=  (time the session is active)
r=* (zero or more repeat times)

Media description
m=  (media name and transport address)
i=* (media title)
c=* (connection information – optional if included at session-level)
b=* (bandwidth information)
k=* (encryption key)
a=* (zero or more media attribute lines)

SAMPLE :

Sent:
INVITE sip:2911111@208.0.0.5:5060 SIP/2.0
Via: SIP/2.0/UDP 65.0.0.57:5060;branch=z9hG4bKB287C
Remote-Party-ID: "NWN" ;party=calling;screen=no;privacy=off
From: "NWN" ;tag=27EFF0FC-2073
To:
Date: Wed, 03 Feb 2010 16:46:25 GMT
Call-ID: 8088F61B-101A11DF-8C6ACB9F-36887B6A@65.0.0.57
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2044219673-270143967-2355415967-914914154
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70in
Timestamp: 1265215585
Contact:
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 240

!SDP HEADER HERE

v=0
o=CiscoSystemsSIP-GW-UserAgent 6135 7812 IN IP4 65.0.0.57
s=SIP Call
c=IN IP4 65.0.0.57
t=0 0
m=audio 19344 RTP/AVP 0 100
c=IN IP4 65.0.0.57
a=rtpmap:0 PCMU/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=ptime:20

*Feb  3 16:46:25.661: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 65.0.0.57:5060;branch=z9hG4bKB287C;received=65.0.0.57
From: "NWN" ;tag=27EFF0FC-2073
To:
Call-ID: 8088F61B-101A11DF-8C6ACB9F-36887B6A@65.0.0.57
CSeq: 101 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact:
Content-Length: 0

*Feb  3 16:46:26.693: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 65.0.0.57:5060;branch=z9hG4bKB287C;received=65.0.0.57
From: "NWN" ;tag=27EFF0FC-2073
To: ;tag=as76f79303
Call-ID: 8088F61B-101A11DF-8C6ACB9F-36887B6A@65.0.0.57
CSeq: 101 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact:
Content-Type: application/sdp
Content-Length: 180

v=0
o=root 24622 24622 IN IP4 208.0.0.5
s=session
c=IN IP4 208.0.0.5
t=0 0
m=audio 12778 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

Now based on http://www.ietf.org/rfc/rfc3551.txt  & http://www.ietf.org/rfc/rfc4317.txt we can conclude, that audio is going to be encoded in PCMU as negotiated

As a side note, the UAS is not negotiating fmtp:100 192-194,

a=fmtp:<format> <format specific parameters>
This attribute allows parameters that are specific to a
particular format to be conveyed in a way that SDP doesn’t have
to understand them. The format must be one of the formats
specified for the media. Format-specific parameters may be any
set of parameters required to be conveyed by SDP and given
unchanged to the media tool that will use this format.

bringing possible issues with DTMF Tones (in-band or out-band) – Where  In-band relates to the RTP media stream, while out-of-band relates to the signaling path.

o=<username> <session id> <version> <network type> <address type>
<address>

=============================================================
o=CiscoSystemsSIP-GW-UserAgent 6135 7812 IN IP4 65.0.0.57
=============================================================

<network type> is a text string giving the type of network.
Initially “IN” is defined to have the meaning “Internet”.  <address
type> is a text string giving the type of the address that follows.
Initially “IP4” and “IP6” are defined.  <address> is the globally
unique address of the machine from which the session was created.
For an address type of IP4, this is either the fully-qualified domain
name of the machine, or the dotted-decimal representation of the IP
version 4 address of the machine.  For an address type of IP6, this
is either the fully-qualified domain name of the machine, or the
compressed textual representation of the IP version 6 address of the
machine.  For both IP4 and IP6, the fully-qualified domain name is
the form that SHOULD be given unless this is unavailable, in which
case the globally unique address may be substituted.  A local IP
address MUST NOT be used in any context where the SDP description
might leave the scope in which the address is meaningful.

In general, the “o=” field serves as a globally unique identifier for
this version of this session description, and the subfields excepting
the version taken together identify the session irrespective of any
modifications.

=========================
m=<media> <port> <transport> <fmt list>

=========================
m=audio 12778 RTP/AVP 0
=========================

m=video 49170/2 RTP/AVP 31

would specify that ports 49170 and 49171 form one RTP/RTCP pair and
49172 and 49173 form the second RTP/RTCP pair.  RTP/AVP is the
transport protocol and 31 is the format

31        H261            V                  90000                              [RFC4587]

session description may contain a number of media descriptions.
Each media description starts with an “m=” field, and is terminated
by either the next “m=” field or by the end of the session
description.

An example of a static payload type is u-law PCM coded single
channel audio sampled at 8KHz.  This is completely defined in the
RTP Audio/Video profile as payload type 0, so the media field for
such a stream sent to UDP port 49232 is:

m=video 49232 RTP/AVP 0

An example of a dynamic payload type is 16 bit linear encoded
stereo audio sampled at 16KHz.  If we wish to use dynamic RTP/AVP
payload type 98 for such a stream, additional information is
required to decode it:

m=video 49232 RTP/AVP 98

http://www.iana.org/assignments/rtp-parameters

=========================
m=audio 12778 RTP/AVP 0
=========================

Registry:
PT        encoding name   audio/video (A/V)  clock rate (Hz)  channels (audio)  Reference
——–  ————–  —————–  —————  —————-  ———
0         PCMU            A                  8000             1                 [RFC3551]

=========================
a=rtpmap:0 PCMU/8000
=========================

a=<attribute>
a=<attribute>:<value>

A media description may have any number of attributes (“a=” fields)
which are media specific.  These are referred to as “media-level”
attributes and add information about the media stream.

Attribute fields can also be added before the first media field; these
“session-level” attributes convey additional information that applies
to the conference as a whole rather than to individual media; an
example might be the conference’s floor control policy.

Attribute fields may be of two forms:

o property attributes.  A property attribute is simply of the form
“a=<flag>”.  These are binary attributes, and the presence of the
attribute conveys that the attribute is a property of the session.
An example might be “a=recvonly”.

o value attributes.  A value attribute is of the form
“a=<attribute>:<value>”.  An example might be that a whiteboard
could have the value attribute “a=orient:landscape”

A Networker Blog

SIP – ohh my!!

I am sorry that I haven’t been on  for a very long time,  dealing with lots of work, however today, I just wanted to share an experience about  what people do with SIP,  using any Sip Soft-phone and pointing the proxy address to a router registered in a SIP Trunk, Non Authorized individuals can perform outbound calls at your own cost!

This gateway is calling a valid SIP registered number

R2(cfg-translation-rule)#do show sip reg status
Line                             peer       expires(sec) registered P-Associ-URI
=========== === ======= ====== ========
2002                             -1         67           yes

Back to the victim router we get this:

/-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:2002@cisco.com SIP/2.0
Via: SIP/2.0/UDP 172.1.1.112:18980;branch=z9hG4bK-d8754z-07178976d20f5e3d-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:5001@172.1.1.112:18980>
To: "2002"<sip:2002@cisco.com>
From: "5001"<sip:5001@cisco.com>;tag=092be37d
Call-ID: OWNhNmQ4Mzk3YjY3YzlkZjhhZjY1MzI4OTdiYjVlZTI.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: X-Lite release 1104o stamp 56125
Content-Length: 332

v=0
o=- 1 2 IN IP4 172.1.1.112
s=CounterPath X-Lite 3.0
c=IN IP4 172.1.1.112
t=0 0
m=audio 60372 RTP/AVP 0 8 101
a=alt:1 3 : NP37ITbQ 7Z5WbGrz 213.16.33.139 60372
a=alt:2 2 : Q0JIKunJ uW14UV3u 172.2.1.111 60372
a=alt:3 1 : sKuD8lqI yL6F082u 172.1.1.112 60372
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=sendrecv
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100
R1(config)#Trying
Via: SIP/2.0/UDP 172.1.1.112:18980;branch=z9hG4bK-d8754z-07178976d20f5e3d-1---d8754z-;rport
From: "5001"<sip:5001@cisco.com>;tag=092be37d
To: "2002"<sip:2002@cisco.com>
Date: Wed, 15 Sep 2010 18:41:09 GMT
Call-ID: OWNhNmQ4Mzk3YjY3YzlkZjhhZjY1MzI4OTdiYjVlZTI.
CSeq: 1 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:2002@6.6.6.6:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.3.140:5060;branch=z9hG4bK2212B1
Remote-Party-ID: "5001" <sip:1001@192.168.3.140>;party=calling;screen=no;privacy=off
From: "5001" <sip:1001@6.6.6.6>;tag=12FA79C-2109
To: <sip:2002@6.6.6.6>
Date: Wed, 15 Sep 2010 18:41:09 GMT
Call-ID: A441F42A-C02F11DF-8296F639-3DF062CE@192.168.3.140
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2755665842-3224310239-2190538297-1039164110
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1284576069
Contact: <sip:1001@192.168.3.140:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 215

v=0
o=CiscoSystemsSIP-GW-UserAgent 6044 0 IN IP4 192.168.3.140
s=SIP Call
c=IN IP4 192.168.3.140
t=0 0
m=audio 18384 RTP/AVP 0 19
c=IN IP4 192.168.3.140
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=ptime:20
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.3.140:5060;branch=z9hG4bK2212B1
From: "5001" <sip:1001@6.6.6.6>;tag=12FA79C-2109
To: <sip:2002@6.6.6.6>
Date: Wed, 15 Sep 2010 18:16:05 GMT
Call-ID: A441F42A-C02F11DF-8296F639-3DF062CE@192.168.3.140
Timestamp: 1284576069
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.3.140:5060;branch=z9hG4bK2212B1
From: "5001" <sip:1001@6.6.6.6>;tag=12FA79C-2109
To: <sip:2002@6.6.6.6>;tag=94CD3D4-BBA
Date: Wed, 15 Sep 2010 18:16:05 GMT
Call-ID: A441F42A-C02F11DF-8296F639-3DF062CE@192.168.3.140
Timestamp: 1284576069
CSeq: 101 INVITE
Require: 100rel
RSeq: 7480
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:6004@192.168.3.136>;party=called;screen=no;privacy=off
Contact: <sip:2002@192.168.3.136:5060>
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.3.140:5060;branch=z9hG4bK2316C4
From: "5001" <sip:1001@6.6.6.6>;tag=12FA79C-2109
To: <sip:2002@6.6.6.6>;tag=94CD3D4-BBA
Date: Wed, 15 Sep 2010 18:16:05 GMT
Call-ID: A441F42A-C02F11DF-8296F639-3DF062CE@192.168.3.140
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 102 PRACK
Content-Length: 0
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
CANCEL sip:2002@cisco.com SIP/2.0
Via: SIP/2.0/UDP 172.1.1.112:18980;branch=z9hG4bK-d8754z-07178976d20f5e3d-1---d8754z-;rport
To: "2002"<sip:2002@cisco.com>
From: "5001"<sip:5001@cisco.com>;tag=092be37d
Call-ID: OWNhNmQ4Mzk3YjY3YzlkZjhhZjY1MzI4OTdiYjVlZTI.
CSeq: 1 CANCEL
User-Agent: X-Lite release 1104o stamp 56125
Content-Length: 0

!! hanged the phone here, not believing on what i was seeing !!!

The solution for this Fraud is to configure

R1(config)#access-list 1 permit 192.168.3.0 0.0.0.255
R1(config)#access-list 1 deny any
R1(config)#voice source-group SIPIN
R1(cfg-source-grp)#access-list 1
R1(cfg-source-grp)#^Z
R1#

The access list that is there is to prevent toll fraud. If the SIP message comes in from a SIP server that is not allowed by this acl, the Gateway would reject the call with “500 Internal Server Error”

//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:2002@cisco.com SIP/2.0
Via: SIP/2.0/UDP 172.1.1.112:18980;branch=z9hG4bK-d8754z-2b7ae0685139182a-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:5001@172.1.1.112:18980>
To: "2002"<sip:2002@cisco.com>
From: "5001"<sip:5001@cisco.com>;tag=9f2fa51e
Call-ID: ZmRlNmEyNGJlNjU3NmIxNzJmOWI1MjM1NzM4MjUzNjc.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: X-Lite release 1104o stamp 56125
Content-Length: 332

v=0
o=- 9 2 IN IP4 172.1.1.112
s=CounterPath X-Lite 3.0
c=IN IP4 172.1.1.112
t=0 0
m=audio 24758 RTP/AVP 0 8 101
a=alt:1 3 : YfWuKpv6 FtHUNojM 213.16.33.139 24758
a=alt:2 2 : +01pKF2W hOqOjQos 172.2.1.111 24758
a=alt:3 1 : Y3arJ6mi i4oz9+5p 172.1.1.112 24758
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=sendrecv
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 500
R1#Internal Server Error
Via: SIP/2.0/UDP 172.1.1.112:18980;branch=z9hG4bK-d8754z-2b7ae0685139182a-1---d8754z-;rport
From: "5001"<sip:5001@cisco.com>;tag=9f2fa51e
To: "2002"<sip:2002@cisco.com>;tag=110E318-D3C
Date: Wed, 15 Sep 2010 18:07:33 GMT
Call-ID: ZmRlNmEyNGJlNjU3NmIxNzJmOWI1MjM1NzM4MjUzNjc.
CSeq: 1 INVITE
Allow-Events: telephone-event
Reason: Q.850;cause=63
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:2002@cisco.com SIP/2.0
Via: SIP/2.0/UDP 172.1.1.112:18980;branch=z9hG4bK-d8754z-2b7ae0685139182a-1---d8754z-;rport
To: "2002"<sip:2002@cisco.com>;tag=110E318-D3C
From: "5001"<sip:5001@cisco.com>;tag=9f2fa51e
Call-ID: ZmRlNmEyNGJlNjU3NmIxNzJmOWI1MjM1NzM4MjUzNjc.
CSeq: 1 ACK
Content-Length: 0

A Networker Blog

All i want to do is to give the victim a voice.!

MPLS NAT Aware Sample Configurations

 

Internet access is perhaps one of the most popular services that Service Providers offer their customers. Customers have flexibility to purchase MPLS VPN services Internet connectivity from separate Service Providers. Customers can alternatively offer Internet connectivity directly from their network may it be from one of their remote sites or the central site. In the latter case, the Internet Service Provider (ISP) does not need to distinguish customer’s Internet and VPN traffic, because all traffic traversing through a Service Provider network would be MPLS VPN traffic.

In MPLS based BGP-VPNs (RFC 2547),  ISPs offered customers an interface that was capable of carrying intranet and internet traffic.

Traffic between intranet and internet in a MPLS BGP-VPNs requires NAT Services at the customer edge router, between the customer private addresses and a globally routable address.

Traditional NAT operation can be summarized as follows:

  • NAT’s interfaces are classified as either inside or outside interfaces
  • Typically inside interface(s) connect to private address space and outside interface connect to global address space.
  • NAT occurs after routing for traffic from inside-to-outside interfaces.
  • NAT occurs before routing for traffic from outside-to-inside interfaces.
  • Routing information must be populated in the next-hop router for prefixes used in the NAT pool that is used for translation, for routing return traffic.

Topology

R3#conf ter
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#
R3(config)#ip vrf 23
R3(config-vrf)#rd 23:23
R3(config-vrf)#route-t 23:23
R3(config-vrf)#
R3(config-vrf)#ip vrf 13
R3(config-vrf)#rd 13:13
R3(config-vrf)#route-t 13:13
R3(config-vrf)#
R3(config-vrf)#int s0/0
R3(config-if)#ip vrf for 13
R3(config-if)#ip add 10.1.13.3 255.255.255.0
R3(config-if)#ip nat inside
R3(config-if)#no sh
R3(config-if)#
R3(config-if)#int s0/1
R3(config-if)#ip vrf for 23
R3(config-if)#ip add 10.1.23.3 255.255.255.0
R3(config-if)#ip nat inside
R3(config-if)#no sh
R3(config-if)#
R3(config-if)#int s0/2
R3(config-if)#ip add 10.1.34.3 255.255.255.0
R3(config-if)#ip nat out
R3(config-if)#no sh
R3(config-if)#exit
R3(config)#access-list 1 permit any
R3(config)#ip route vrf 13 1.1.1.1 255.255.255.255 10.1.13.1
R3(config)#ip route vrf 13 0.0.0.0 0.0.0.0 10.1.34.4 global
R3(config)#
R3(config)#ip route vrf 23 2.2.2.2 255.255.255.255 10.1.23.2
R3(config)#ip route vrf 23 0.0.0.0 0.0.0.0 10.1.34.4 global
R3(config)#
R3(config)#ip nat pool MYPOOL 10.1.34.50 10.1.34.255 netmask 255.255.255.0
R3(config)#ip nat inside source list 1 pool MYPOOL vrf 13
R3(config)#
R3(config)#ip nat inside source list 1 pool MYPOOL vrf 23
R3(config)#

Inside to Outside packet flow:

NatIntoOUt

NAT get hold of the packet, and does the translation (static or dynamic) and also stores the VRF table ID in the translation entry.

R3#show ip nat translations verbose
Pro Inside global      Inside local       Outside local      Outside global
icmp 10.1.34.50:5      10.1.23.2:5        4.4.4.4:5          4.4.4.4:5
create 00:00:10, use 00:00:00 timeout:60000, left 00:00:59, Map-Id(In): 2,
flags:
extended, use_count: 0, VRF : 23, entry-id: 3, lc_entries: 0
--- 10.1.34.50         10.1.23.2          ---                ---
create 00:16:50, use 00:00:11 timeout:86400000, left 23:59:48, Map-Id(In): 2,
flags:
none, use_count: 1, VRF : 23, entry-id: 1, lc_entries: 0

Outside to Inside packet flow:

image

NAT receives the packet before routing and performs lookup on the translation table. NAT performs the reverse translation, and also sets the VRF table ID in the packet descriptor header. This enables the subsequent route lookup to occur on the right Forwarding Information Block (FIB). If the outgoing interface is in a VRF on the same PE, then the packet is forwarded as an IP packet. If the destination is on a remote PE, then the packet is imposed with labels and forwarded on the core facing interface.

A Networker Blog

%LDP-4-PWD: MD5 protection is required!

MPLS LDP messages (discovery, session, advertisement, and notification messages) are exchanged between LDP peers through two channels:

  • LDP discovery messages are transmitted as User Datagram Protocol (UDP) packets to the well-known LDP port.
  • Session, advertisement, and notification messages are exchanged through a TCP connection established between two LDP peers.

The MPLS LDP—Lossless MD5 Session Authentication feature allows an LDP session to be password-protected without tearing down and reestablishing the LDP session.

Old Style

New Style

R2(config)#mpls ldp neighbor 1.1.1.1 password 123
R2(config)#! 
R2(config-if)#interface Ethernet  1/0
R2(config-if)#  ip address 192.168.1.2  255.255.255.0
R2(config-if)#  mpls ip

R2(config)#access-list 99  permit 1.1.1.1
R2(config)#mpls ldp password required for 99
R2(config)#mpls ldp password option 1 for 99 KC
R2(config)#!
R2(config)#key chain KC
R2(config-keychain)#key 1
R2(config-keychain-key)#  key-string password
R2(config-keychain-key)#!
%LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (1) is UP

The disadvantage of using the old method is that when new password is required for a session,  this change would require the LDP session to be tear down. With this feature New passwords can be implemented/changed  without having to tear down the existing LDP session

KeyChain4LDP

A Networker Blog