Cisco IP Multiplexing

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 1© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 1© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 11© 2010 Cisco and/or its affiliates. All rights reserved.

Cisco IP Multiplexing

© 2010 Cisco and/or its affiliates. All rights reserved. 2

Important note:• A number of the slides in this presentation are animated. When

viewing this presentation please run it in slideshow mode.


VoIP over Satellite – the pps problem

• Satellite modems can transmit a limited number of packets per second• Typically 1800 – 2000 pps

• VoIP generates a large number of small packets• Common rate is 100 pps for each call• Causes inefficient use of available bandwidth• Modem runs out of packet-per-second “slots” before all available bandwidth is utilized

Remote Site Main Site

Bandwidth usage

Packets per second0%

0% 100%

100%

IP PhonesIP Phones

VoIP Call

Satellite Modem Satellite Modem


VoIP over Satellite – the pps solution

• Cisco IP multiplexing combines many smaller packets into one larger packet• automatically engages when multiple packets are heading for the same destination

• Larger packets allow for increased packets-per-second efficiency• Connecting additional VoIP calls does not increase packets-per-second• Remaining packets-per-second makes bandwidth available for other applications

Remote Site Main Site

Bandwidth usage

Packets per second0%

0% 100%

100%

VoIP CallIP MultiplexTunnel

IP Phones IP Phones

Satellite Modem Satellite ModemIP MUX IP MUX


The solution – Cisco IP Multiplexing• New interface output feature, like ACLs or QoS

• Combine multiple packets into single, larger, packet• Packets are multiplexed by wrapping a new IP/UDP header around combined packets:

• Transparent to application, works at layer 3• Can multiplex any IP packet

• Works in hub and spoke topology, IP multiplexing-enabled router is required at each end

• Intermediate hops are supported• Multiplexed packets look just like regular IP packets to non ip multiplexing-enabled devices

• Supports IPv4 and IPv6

IP UDP IP UDP RTP DATA IP UDP RTP DATA

New IP/UDP header Data Packet 1 Data Packet 2


Mux

No Mux

Understanding basic operation• Operates as an interface output feature

Egress Interface

IP Mux Feature

Mux Hold-Queue

IP /UDP Packet Packet Packet

Packet

Transmit Packet

PacketPacketPacket


Supported platforms / licensing• Supported on:

• Cisco 892, 819, 29xx, and 39xx• Cisco 5915ESR, 5940ESR

• Licensing• Licensed using standard RTU (right-to-use) feature license

• no license file to install, honor-based, paper license• Must be licensed on each node performing IP multiplexing

• Status• Available in 15.2(2)GC IOS Q1CY12

• (29xx, 39xx, 59xx)• Available in 15.2(4)M IOS Q3CY12

• (819, 892, 29xx, 39xx)

Cisco Confidential 8© 2010 Cisco and/or its affiliates. All rights reserved.

IP multiplexing in action


Baseline – No IP mux, no IPsec

• 18 VoIP calls, G.729 codec (20ms sample), consumes 1800pps

• VoIP is consuming 100% of the modem packets/sec capacity• 4 mbps of remaining bandwidth is wasted, modem cannot transmit excess packets/sec• Other applications cannot use extra bandwidth, no more calls possible

• Maximum calls possible, without degradation – 18

hub#show int g0/2 | inc rate 30 second input rate 535000 bits/sec, 903 packets/sec 30 second output rate 533000 bits/sec, 901 packets/sec

Hub SpokeLAN

WAN

LANSatellite connection5mbps BW, 1800packets/sec

Hub Router, WAN-side interface1800 packets/sec consumed


IP mux, no IPsec

• 18 VoIP calls, G.729 codec (20ms sample), consumes just 100pps, 90% reduction

• Modem has 1700 packets/sec left over

• Remaining bandwidth, ~4mbps, is available to other applications, or additional voip calls

Hub SpokeLAN

WAN

LAN


Satellite connection5mbps BW, 1800packets/sec


Without mux:

With mux:




Baseline – No IP mux, with IPsec

• 18 VoIP calls, G.729 codec (20ms sample), uses 1.8 mbps• 1 mbps for VoIP traffic• 800 kbps for IPsec overhead

• IPsec increases bandwidth consumption of VoIP by ~80%• IPsec overhead consumes 17% overall link bandwidth

• Remaining bandwidth – 3 mbps



Hub SpokeLAN

WANLAN

IPsec Tunnel

Hub Router, WAN-side interface1.8 mbps consumed

Hub Router, LAN-side interface1 mbps consumed

WAN connection5 mbps bandwidth


IP mux, with IPsec

• 18 VoIP calls, G.729 codec (20ms sample), uses 1.8mbps

• Mux reduced IPsec overhead by 94%

• Remaining bandwidth – 4 mbps, a 33% increase


Hub SpokeLAN

WANLAN

IPsec Tunnel

WAN connection5 mbps bandwidth


Without mux:

With mux:

Hub Router, WAN-side interface1.8 mbps consumed

Hub Router, WAN-side interface940 kbps consumed


Benefits of Cisco IP Multiplexing• Single box solution

• No need to for additional piece of equipment• IOS feature

• Single CLI, no need for additional configuration, management, or training

• Easily add IP mux to existing network via IOS software upgrade

• No manipulation of voice stream, codec quality is maintained

• No need to duplicate dial plans or deal with complex call routing• IP mux does not interact with VoIP

• Ability to multiplex any IP packet, not just VoIP• Other good targets include video and other small UDP streams


Bandwidth reduction methods• IP multiplexing does not compress any packets (VoIP or otherwise)

• Method 1 - Tune the VoIP packetization rate• Increase number of voice samples per packet

• Larger packets, but less overhead

• Supported by CUCM, CME, IP phones, gateways, CUBE• Example, increase sample size from 20ms to 40ms:

• Method 2 - Leverage IP mux on data traffic to reduce IPsec overhead• Saves 56 bytes per packet• cRTP only saves 36 bytes per packet and applies only to VoIP


hub#sho int g0/2 | inc rate 30 second input rate 169000 bits/sec, 25 packets/sec 30 second output rate 169000 bits/sec, 25 packets/sec

10 calls, 20ms rate, with IP mux:

10 calls, 40ms rate, with IP mux:



34% bandwidth reduction

Cisco Confidential 15© 2010 Cisco and/or its affiliates. All rights reserved.

Configuration


Configuration checklist• Create ACL to identify interesting traffic

• Create ip mux profile• Attach ACL to profile• Define source interface / address• Define destination address

• Enable ip mux on egress interface

• Activate ip mux profile

• IP mux policies (optional)

• Additional commands (optional)


Creating ACLs for IP mux• Access lists are used to identify interesting traffic

• Numbered and named lists are supported

• Access list criteria is restricted, use only:• Destination IP address• Destination port (or port range)• Protocol• DSCP

• Do not create overlapping / ambiguous ACLs

• Any time changes are made to an ACL already attached to a profile that profile MUST be reset with “shutdown / no shutdown”

• Console messages will remind you which profile to reset:

% You must shut/no shut profile profile-1 to use this ACL for IP Multiplexing.


IP mux profiles• Creates a point-to-point IP mux

connection

• Profiles start in “shutdown” state• multiplex operation will not happen

when profile is shutdown• demultiplex operation will happen with

profile shutdown• Configure BOTH routers before issuing

“no shut” on the respective profiles

• Profiles have global scope• all profiles apply to all interfaces with “ip

mux” configured

• Source / destination addresses must match at each end

• Incoming superframes will be ignored otherwise

• Mandatory items• source address• destination address• access-list

ip mux profile rtp destination 20.1.1.2 source interface g0/0 access-list mux-rtp no shutdown!ip mux profile sjc destination 30.1.1.2 source interface g0/1 access-list mux-sjc no shutdown!


Enable mux on egress interface• Mux is enabled on a per interface basis

• All profiles are evaluated by any interface with mux enabled

• Supported interface types• Ethernet• GRE (IPv4 / IPv6)• VLAN• VMI over Ethernet• Virtual Template on VMI

interface GigabitEthernet0/0 ip mux!


Example ConfigHub

Fa0/1Gig0/2.14 Fa0/03945 5915

Spoke

LANGig0/1

WAN LAN

10.1.1.x/24 10.1.3.x/24

30.1.1.1/24 30.1.1.2/24

ip access-list extended profile-1-acl permit udp any 10.1.3.0 0.0.0.255!ip mux profile profile-1 destination 30.1.1.2 source interface GigabitEthernet0/2.14 access-list profile-1-acl!interface GigabitEthernet0/2.14 description to 5915 ip address 30.1.1.1 255.255.255.0 ip mux!ip mux profile profile-1 no shutdown!

ip access-list extended profile-2-acl permit udp any 10.1.1.0 0.0.0.255!ip mux profile profile-2 destination 30.1.1.1 source interface FastEthernet0/0 access-list profile-2-acl!interface FastEthernet0/0 description to 3945 ip address 30.1.1.2 255.255.255.0 ip mux!ip mux profile profile-2 no shutdown!

Hub Configuration Spoke Configuration


Additional profile commands

spoke(config)#ip mux profile profile-1spoke(config-ipmux-profile)#maxlength ? <64-1472> IP total length value

• maxlength (default: 1472 bytes)

• How large of a packet should we multiplex with other packets?• The larger the packets, the lower the mux ratio

• Cannot be set above the mtu

spoke(config)#ip mux profile profile-1spoke(config-ipmux-profile)#mtu ? <256-1500> Maximum super-frame length

• mtu (default: 1500 bytes)

• How large of a multiplexed packet should we make?• Value includes IP mux overhead ( 28 bytes )

• “mtu 1500” will mux a maximum of 1472 bytes

• Interface MTU is NOT automatically calculated• Do not set mux MTU higher than interface MTU


Additional profile commands continued…

spoke(config)#ip mux profile profile-1spoke(config-ipmux-profile)#holdtime ? <20-250> Number of milliseconds

• holdtime (default: 20 ms)

• How long should we hold packets in the hold-queue?• The longer the holdtime the more (potential) delay IP mux will add

spoke(config)#ip mux profile profile-1spoke(config-ipmux-profile)#ttl ? <1-255> TTL Value

• ttl (default: 64)

• Sets TTL value in IP header of superframe• Most customers should never need to adjust this


Additional general commands

spoke(config)#ip mux profile profile-1spoke(config-ipmux-profile)#[no] shutdown

• shutdown (default: shutdown)

• Profiles default to “shutdown” state• Profile must be “shutdown” when making changes to the attached ACL

spoke(config)#ip mux udpport ? <1024-49151> UDP port number

• ip mux udpport (default: 6682)

• Specifies the source / destination port for IP mux operation• must be the same on all routers


Mux Hold-Queue

Understanding the QoS impact• Similar to the “qos pre-classify” problem of IPsec

• Traffic classifiers see only the IP header of the superframe• By default the DSCP is 0

• QoS classification via DSCP is no longer accurate

ACL matching Packets Outgoing Superframe

DSCP 0

DSCP EF

DSCP CS7

DSCP CS7

DSCP EF

DSCP 0

IP/UDPDSCP 0

Superframe header masks the DSCP values of the packets contained therein


QoS Solution

policy QUEUE 1

Match CS7, EFSet EF

policy QUEUE 2

Match AF31Set AF31

Default Queue

Match AllSet 0

DSCP CS7

DSCP EF

ACL matching Packets

DSCP AF31

DSCP AF31

DSCP 0

DSCP CS5

Outgoing Superframes

DSCP AF31

DSCP AF31

IP/UDPDSCP AF31

DSCP CS7 DSCP EF IP/UDPDSCP EF

DSCP CS5 DSCP 0 IP/UDPDSCP 0

• IP multiplex policies• Match DSCP values, assign DSCP value to IP multiplex header


Understanding profiles and policies• Each profile has at least one policy (default)

• Sets DSCP 0 on outbound superframes

• Default policy is used if no match is found in other policies (or no other policies exist)

• Each ip mux policy adds a new hold queue to ALL configured profiles

ip mux profile rtp

ip mux policy one matchdscp cs7 matchdscp ef outdscp ef!

ip mux policy two matchdscp cs7 matchdscp ef outdscp ef!

ip mux profile sjc

policy QUEUE one

Match CS7, EFSet EF

policy QUEUE two

Match AF31Set AF31

Default Policy Queue

Match AllSet 0

policy QUEUE one

Match CS7, EFSet EF

policy QUEUE two

Match AF31Set AF31

Default Policy Queue

Match AllSet 0


“singlepacket” command• By default, IP multiplexing generates superframes containing a

single packet• Packets will always be muxed, even if only one is in the queue

• Can be used to simplify firewall rule sets:

spoke(config)#ip mux profile profile-1spoke(config-ipmux-profile)#[no] singlepacket

Hub

Fa0/13945 5915

Spoke

LANGig0/1 WAN LAN

10.1.1.x/24 10.1.3.x/24

30.1.1.2/24

IP Multiplex Tunnel

• Firewall only needs to permit udp traffic from 30.1.1.2:6682 to 30.1.1.1:6682

• IP phone media traffic will be obscured by the IP multiplex tunnel• End-to-end firewall configuration is not required

30.1.1.1/24

Cisco IP Multiplexing

Documents

Transcript of Cisco IP Multiplexing