[cisco-voip] ISP and VPN Failover for Call Manager based VOIPnetwork

[Aman Chugh]

I kinda agree with Matthew,I have been having mix results for Voice Quality
with a Site to Site VPN  with a 2801 and PIX on the other end,I have
configured QOS and now when ever I use g729 codec ,I get terrible voice
quality and if i change it back to g711 it's is very good,but cant use g711
as it consumes quite a lot of bandwitdh On 512 kbps link with the VPN
header.I have a TAC case openned and Tac has recommened to try somethings
out.I will keep you guys posted.

Aman


On 9/13/06, Linsemier, Matthew <MLinsemier at apcapital.com> wrote:
>
>   Manoj,
>
>
>
> Do you currently have private lines or some other circuits interconnecting
> your offices or are you planning to use VPN exclusively for voice and data?
> My major concern when using a Cisco PIX for voice would be Quality of
> Service.  While the PIX can preserve DSCP values as they are passed across
> the tunnels, unless anything has changed in 7.x, it doesn't have the
> ability to perform marking, LLQ prioritization, and traffic shaping.  This
> means that before any traffic is passed to the PIX, the device behind it (a
> switch or router) will have to perform some of these functions (say marking
> or traffic shaping).  In regards to LLQ you are out of luck.
>
>
>
> For our Teleworker VPN network we utilize a 2851 at the head-end and
> failover site and 871/877 routers at our remotes.  This gives us the
> capability to mark, LLQ, and shape traffic at the edge, before it is passed
> on to the ISP.  Additionally we utilize DMVPN and GRE to maintain routing
> information (EIGRP) and to dynamically handle routing changes when we loose
> a VPN link (say to our head-end).  I think you can do some least cost
> routing type things on the PIX to achieve the same effect, but it's much
> easier in IOS.
>
>
>
> Your ideas are sound in my opinion.  I'm sure that there are some people
> that are handling voice fine using Cisco PIX's however we had mixed results
> when we were using them.  Once we moved to the IOS VPN several of our QoS
> issues were resolved.  Regardless, you always have to remember that it still
> is the Internet and not a private network connection, so you get what you
> get.
>
>
>
> Hope this helps,
>
>
>
> -Matt
>
>
>  ------------------------------
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Manoj Kalpage
> *Sent:* Wednesday, September 13, 2006 5:20 AM
> *To:* cisco-voip at puck.nether.net
> *Subject:* [cisco-voip] ISP and VPN Failover for Call Manager based
> VOIPnetwork
>
>
>
> Dear All,
>
> I am looking for ISP fail over for VoIP network. We have small
> enterprise VoIP network. If I explain our network bit, Basically we
> have call manager and unity server in main office with PIX515. All the
> branch offices has PIX 501. With attached fail over solution I am going to
> create two tunnels from each branch office and have them connected to each
> firewall in main office. I think this way if one PIX515 fail at main office,
> still branch office can be connected through second PIX515. Bellow is the
> router configuration for routing between two PIX 515. This configuration
> itself doesn't mean anything without looking at a diagram.I need to test
> this but I don't have enough gears with me right now and also I don't have
> 100% confidence on this. So, I would like to share with you folks. Any
> comments and ideas would be greatly appreciated.
>
>
>
> Please find the diagram bellow link (Sorry it's han written one )
>
>
> http://proxy.f2.ymdb.yahoofs.jp/bc/857e55a/bc/bd7f/failover.jpg?bcQM9BFBNirrJIWq
>
>
>
> best regards,
>
> Manoj
>
>
>
>
> ip cef
>
> !####Establish sla monitors for use in tracking objects####!
>
> ip sla monitor 1
> type echo protocol ipIcmpEcho 174.16.0.1
> threshold 3
> frequency 5
> ip sla monitor schedule 1 life forever start-time now
>
> ip sla monitor 2
> type echo protocol ipIcmpEcho 173.16.0.1
> threshold 3
> frequency 5
> ip sla monitor schedule 2 life forever start-time now
> !
>
> !####Configure Tracking objects (referencing IP SLA monitor's above)####!
>
> track 101 rtr 1 reachability
> !
> track 102 rtr 2 reachability
> !
> !
> !
> !
> !####Configure Interfaces with NAT####!
>
> interface FastEthernet 0/1
> ip address 172.16.0.1 255.255.0.0
> ip nat inside
>
> !
> interface Fastethernet 0/0
> ip address 173.16.0.2 255.255.255.0
> ip nat outside
>
> !
> interface Fastethernet 0/2
> ip address 174.16.0.2 255.255.255.0
> ip nat outside
>
> !
> ip classless
> !####Configure gateway of last resort with tracking objects####!
> ip route 0.0.0.0 0.0.0.0 173.16.0.1 track 101
> ip route 0.0.0.0 0.0.0.0 174.16.0.1 track 102
>
> !####Configure NAT statements for most outbound traffic####!
> ip nat inside source route-map ISP1 interface FastEthernet 0/0 overload
> ip nat inside source route-map ISP2 interface FastEthernet 0/2 overload
>
> !
> access-list 10 permit 172.16.0.0 0.0.0.255
> access-list 101 permit icmp any host 173.16.0.1 echo
> access-list 102 permit icmp any host 174.16.0.1 echo
>
> !
> !####Configure route maps for reference in NAT statements####!
> route-map ISP2 permit 10
> match ip address 10
> match interface Fastethernet 0/1
> !
> route-map ISP1 permit 10
> match ip address 10
> match interface Fastethernet 0/0
> !
>
>
>
>
>  ------------------------------
>
> *CONFIDENTIALITY STATEMENT*
>
> This communication and any attachments are *CONFIDENTIAL* and may be
> protected by one or more legal privileges. It is intended solely for the use
> of the addressee identified above. If you are not the intended recipient,
> any use, disclosure, copying or distribution of this communication is *
> UNAUTHORIZED*. Neither this information block, the typed name of the
> sender, nor anything else in this message is intended to constitute an
> electronic signature unless a specific statement to the contrary is included
> in this message. If you have received this communication in error, please
> immediately contact me and delete this communication from your computer.
> Thank you.
>
> ------------------------------
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20060913/39b3a2bc/attachment-0001.html