cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2222
Views
0
Helpful
14
Replies

Voice traffic on BGP MPLS

Rupesh Kashyap
Level 1
Level 1

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.

14 Replies 14

milan.kulik
Level 10
Level 10

Hi,

generally, tuning BGP timers could bring you fats convergence, see

http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_bgp4.html#wp1011411

for details.

But IMHO, GRE tunnels would not bring you any good.

What you'll need for a good voice quality is QoS settings to support VoIP over your backbone.

HTH,

Milan

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.

I suppose you are not the owner of the MPLS backbone?

You can ask you provider if any advanced feature is implemented to speed up the backbone convergence, see

http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_te_frr_node_prot_ps6922_TSD_Products_Configuration_Guide_Chapter.html#wp1454064

for an example.

BR,

Milan

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.

Yes, I've got the same experience.

bgp fast-external-fallover is enabled by default.

See

http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfbgp1.html#wp1018146

for details.

BR,

Milan

Mohamed Sobair
Level 7
Level 7

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

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
Hall of Fame
Hall of Fame

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.

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

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.

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

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.

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

Hi,

yes, OER Fast Failover Monitoring

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

seems to be the way.

But the configuration is pretty complex, I never used OER :-(

Do you have some experience with that?

Thanks,

Milan

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco