Voice traffic on BGP MPLS

Unanswered Question
Feb 3rd, 2010
User Badges:

Hi,


I have two routers in India and two in US. They all on MPLS and we are running BGP on that. My VOIP PBX is on US and India users (total 900) has to connect VOIP phones having US call server. Now my questions are-


1. Should I configure any EIGRP GRE tunnel over BGP protocol for good voice quality & fast convergence ?

2. If any link will down, how fast BGP will recalculate/ readvertise the route on redundant link? I am looking for very fast failover.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Rupesh Kashyap Wed, 02/03/2010 - 05:15
User Badges:

What about if there would any problem with ony router in the MPLS path, then how frequently it we will found the path in India and US routers in BGP table.

Rupesh Kashyap Wed, 02/03/2010 - 06:28
User Badges:

Hi, I have noticed that if interface on my router would down, BGP is showing down immediately. I haven't configured any timer, it is on default timer.


Any idea why it is happening? Any relation with fast failover default BGP feature.

Mohamed Sobair Wed, 02/03/2010 - 06:55
User Badges:
  • Gold, 750 points or more

Hi,


By default in recent IOS release, (BGP fast external failover) is enabled, when this feature is enabled , if the neighbor goes down (Physically Interface is down), bgp detects immediately the failure and converge over to the second path.


Tweaking the timers of the BGP are helpfull whenever the neigbor is not reachable , because if the neigbor is not reachable, BGP does wait for 3 Keep alives till it terminate the session completely and converge



HTH

Mohamed

Rupesh Kashyap Wed, 02/03/2010 - 08:12
User Badges:

What about if India ISP is ok & link on US end is down, then how much time India router will take to get the information to remove the route?

Edison Ortiz Wed, 02/03/2010 - 13:21
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

Your concern is valid.


With MPLS VPN, since the provider is doing L3 routing for you, you have to trust the backbone does not have any 'blackholes'.

You are concentrating your efforts on convergence and voice quality.


The voice quality can be easily accomplished with QoS between you and the provider (you must pay extra for that).


As for convergence (CE to PE), it can be easily accomplished with BGP timers.


But, what if the routers are getting the routes from either end - the peering is up - but

what if traffic is getting blackholed due to a label failure somewhere in the backbone?


You won't be able to tell from your BGP session unless you either implement GRE (keepalives will detect failure in the cloud)

or adding an additional BGP peering between CEs.


The latter is something that is preferred over the GRE design. All you need to do is advertise the loopbacks to the PE and then create another BGP peer between CEs by using those advertised loopbacks.


If the MPLS Cloud fails, so will the CE BGP session.

milan.kulik Thu, 02/04/2010 - 00:00
User Badges:
  • Red, 2250 points or more

Hi Edison,


so you are suggesting to create a full-mesh multihop eBGP between all customer CE routers to detect a possible label failure in the provider backbone?

Which prefixes should be advertised via those BGP sessions? Loopbacks only?


Would that really bring some new quality to a failure detection?


The customer CE-CE BGP session will take the same path as MP-BGP session between the provider PEs, won't it?

So in a case of backbone blackhole the MP-BGP session keepalives should be lost, too, and the user prefixes withdrawn from the customer VRF finally?

So the only chance to improve failure detection would be decreasing customer BGP timers, possibly?


I might be missing something, can you please provide more details?


Thanks,

Milan

Edison Ortiz Thu, 02/04/2010 - 12:16
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

so you are suggesting to create a full-mesh multihop eBGP between all customer CE routers to detect a possible label failure in the provider backbone?


Yes. I understand this design has scalability issues but for small environments this design provides resilience in case of MPLS Label failure in the provider backbone.


Which prefixes should be advertised via those BGP sessions? Loopbacks only?


You advertise your loopbacks to the PE, then advertise your internal routing via the CE<->CE peering.


Would that really bring some new quality to a failure detection?


If there is a blackhole in the MPLS cloud, the CE<->CE BGP peering will go down as the loopbacks aren't reachable.



The customer CE-CE BGP session will take the same path as MP-BGP session between the provider PEs, won't it?


Yes, they take the same path but the CE<->CE BGP session requires the MP-BGP to carry the labels end-to-end.

The PE-PE MP-BGP session only requires unicast routing end-to-end. There is no way to automatic check for label failure at the PE level.

A MP-BGP session will not go down due to label failure in the MPLS Backbone.


So in a case of backbone blackhole the MP-BGP session keepalives should be lost, too, and the user prefixes withdrawn from the customer VRF finally?


No, they won't be lost as MPLS Label failure can occur anywhere in the backbone. PE<->PE connection will be maintained, only labels will be affected.


So the only chance to improve failure detection would be decreasing customer BGP timers, possibly?


Not on Label Failure.

Giuseppe Larosa Thu, 02/04/2010 - 14:12
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Milan,

from Edison's answers my guess is that he is probably referring to BGP Carrier Supporting Carrier using BGP with labels


http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_carrier_bgp_ps6441_TSD_Products_Configuration_Guide_Chapter.html


the idea is that the MPLS VPN provider is used only to provide IP connectivity between loopbacks of CE nodes.

CE nodes in their turn act as PE nodes with the help of provider network.


Without using BGP with labels or point to point GRE tunnels should be used or each CE should have at the same time an eBGP session with PE node and iBGP session with remote CE advertising internal routes on both sessions.


As Edison noted, a BGP session between PE nodes can use the existing LSPs between PE nodes as user traffic (including traffic having a BGP next-hop = remote PE loopback) but the session does not fail in case the LSP is broken somewhere it can be routed in IP inside the provider backbone.

MPLS L3 VPN connectivity fails if LSP with destination remote PE loopback fails even if only in one direction.


Hope to help

Giuseppe

Edison Ortiz Thu, 02/04/2010 - 18:30
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

Giuseppe,


I not referring to CSC nor BGP+Labels.


I'm simply recommending a way to test end-to-end IP connectivity between CEs.

You do so by configuring BGP peers between CEs since BGP on itself will provide a mechanism (hello packets) to determine if the remote IP is reachable.

You can do the same design by using GRE tunnels (keepalive mechanism) but it brings other issues such as fragmentation.


You don't need to exchange labels at the CE-CE BGP peering, it's pure IP routing.

antasson Fri, 02/05/2010 - 00:08
User Badges:
  • Cisco Employee,

Hi all,

I think in this case IP SLA would be useful.


You can also think of multi-homing (to different providers), and use IP SLA or PFR to choose the best-performing outbound path.


Here's some link:


IP SLA:

http://www.cisco.com/en/US/docs/ios/12_3/12_3x/12_3xe/feature/guide/dbackupx.html#wp1071672


PFR (aka OER):

http://www.cisco.com/en/US/docs/ios/oer/configuration/guide/oer-overview.html


Hope it helps.

Antonio

Actions

This Discussion