320 likes | 504 Views
Cisco IP Multiplexing. 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. Bandwidth usage. Satellite modems can transmit a limited number of packets per second
E N D
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 Bandwidth usage • 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 100% 0% Packets per second 0% 100% Satellite Modem Satellite Modem Remote Site Main Site IP Phones IP Phones VoIP Call
VoIP over Satellite – the pps solution Bandwidth usage • 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 100% 0% Packets per second 0% 100% IP MUX IP MUX Satellite Modem Satellite Modem Remote Site Main Site IP Phones IP Phones IP Multiplex Tunnel VoIP Call
The solution – Cisco IP Multiplexing • New interface output feature, like ACLsor 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 Data Packet 1 New IP/UDP header Data Packet 2
Understanding basic operation Transmit Packet • Operates as an interface output feature Egress Interface IP Mux Feature Packet Packet Packet Packet Mux No Mux
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)
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 WAN LAN LAN Satellite connection 5mbps BW, 1800packets/sec Spoke Hub hub#showintg0/2 | inc rate 30 second input rate 535000 bits/sec, 903 packets/sec 30 second output rate 533000 bits/sec, 901 packets/sec Hub Router, WAN-side interface 1800 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 WAN LAN LAN Satellite connection 5mbps BW, 1800packets/sec Spoke Hub Without mux: Hub Router, WAN-side interface 1800 packets/sec consumed hub#showintg0/2 | inc rate 30 second input rate 535000 bits/sec, 903 packets/sec 30 second output rate 533000 bits/sec, 901 packets/sec With mux: hub#showintg0/2 | inc rate 30 second input rate 450000 bits/sec, 50 packets/sec 30 second output rate 449000 bits/sec, 50 packets/sec Hub Router, WAN-side interface 100 packets/sec consumed
Baseline – No IP mux, with IPsec WAN connection 5 mbps bandwidth • 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 LAN LAN WAN Spoke Hub IPsec Tunnel Hub Router, WAN-side interface 1.8 mbps consumed hub#showintg0/2 | inc rate 30 second input rate 969000 bits/sec, 904 packets/sec 30 second output rate 966000 bits/sec, 901 packets/sec hub#showintg0/1 | inc rate 30 second input rate 534000 bits/sec, 901 packets/sec 30 second output rate 535000 bits/sec, 904 packets/sec Hub Router, LAN-side interface 1 mbps consumed
IP mux, with IPsec WAN connection 5 mbps bandwidth • 18 VoIP calls, G.729 codec (20ms sample), uses 1.8mbps • Mux reduced IPsec overhead by 94% • Remaining bandwidth – 4 mbps, a 33% increase LAN LAN WAN Spoke Hub IPsec Tunnel Without mux: hub#showintg0/2 | inc rate 30 second input rate 969000 bits/sec, 904 packets/sec 30 second output rate 966000 bits/sec, 901 packets/sec Hub Router, WAN-side interface 1.8 mbps consumed With mux: hub#showintg0/2 | inc rate 30 second input rate 470000 bits/sec, 50 packets/sec 30 second output rate 469000 bits/sec, 51 packets/sec Hub Router, WAN-side interface 940 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 • cRTPonly saves 36 bytes per packet and applies only to VoIP 10 calls, 20ms rate, with IP mux: Hub Router, WAN-side interface 500 kbps consumed hub#showintg0/2 | inc rate 30 second input rate 257000 bits/sec, 50 packets/sec 30 second output rate 257000 bits/sec, 50 packets/sec 10 calls, 40ms rate, with IP mux: Hub Router, WAN-side interface 330 kbps consumed 34% bandwidth reduction hub#shointg0/2 | inc rate 30 second input rate 169000 bits/sec, 25 packets/sec 30 second output rate 169000 bits/sec, 25 packets/sec
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 Config Spoke Hub WAN Fa0/1 Gig0/1 Gig0/2.14 Fa0/0 3945 5915 30.1.1.2/24 30.1.1.1/24 LAN LAN 10.1.1.x/24 10.1.3.x/24 Hub Configuration Spoke Configuration ip access-list extended profile-1-acl permit udpany 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 ipaddress 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 udpany 10.1.1.0 0.0.0.255 ! ipmux 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 ipmux ! ip mux profile profile-2 no shutdown !
Additional profile commands • maxlength (default: 1472 bytes) spoke(config)#ip mux profile profile-1 spoke(config-ipmux-profile)#maxlength ? <64-1472> IP total length value 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 • mtu (default: 1500 bytes) spoke(config)#ip mux profile profile-1 spoke(config-ipmux-profile)#mtu ? <256-1500> Maximum super-frame length 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… • holdtime (default: 20 ms) spoke(config)#ip mux profile profile-1 spoke(config-ipmux-profile)#holdtime ? <20-250> Number of milliseconds How long should we hold packets in the hold-queue? The longer the holdtime the more (potential) delay IP mux will add • ttl(default: 64) spoke(config)#ip mux profile profile-1 spoke(config-ipmux-profile)#ttl ? <1-255> TTL Value Sets TTL value in IP header of superframe Most customers should never need to adjust this
Additional general commands • shutdown (default: shutdown) spoke(config)#ip mux profile profile-1 spoke(config-ipmux-profile)#[no] shutdown Profiles default to “shutdown” state Profile must be “shutdown” when making changes to the attached ACL • ip mux udpport(default: 6682) spoke(config)#ip mux udpport ? <1024-49151> UDP port number Specifies the source / destination port for IP mux operation must be the same on all routers
Understanding the QoS impact • Similar to the “qospre-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 Superframe header masks the DSCP values of the packets contained therein
QoS Solution • IP multiplex policies • Match DSCP values, assign DSCP value to IP multiplex header ACL matching Packets Outgoing Superframes
ip mux profile rtp ip mux profile sjc 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 policy one matchdscp cs7 matchdscpef outdscpef ! ip mux policy two matchdscp cs7 matchdscpef outdscpef !
“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: LAN LAN spoke(config)#ip mux profile profile-1 spoke(config-ipmux-profile)#[no] singlepacket IP Multiplex Tunnel Spoke Hub WAN Fa0/1 Gig0/1 3945 5915 30.1.1.2/24 30.1.1.1/24 10.1.1.x/24 10.1.3.x/24 • 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