cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3748
Views
0
Helpful
21
Replies

BGP backdoor

Latchum Naidu
VIP Alumni
VIP Alumni

Hi All,

I have the below setup for three sites.

Will --->10 Mb internet ---> 20 Mb internet ---->DC (connect through DMVPN and EIGRP is the protocol running)
DC --->8 Mb MPLS ---> 2 Mb MPLS ---> Will (Connect through MPLS mesh and BGP is protocol running)
Cux ---> 2 Mb DSL ---> 20 Mb internet ---DC (connect through Easy VPN)

Find the attached one for the same:

I have used BGP backdoor command to pass the traffic from "DC" to "Will" through DMVPN it is working fine in two ways (Will to DC & DC to Will)


We have another site "Cux" when they are accessing DC is working fine, but when they are accessing "Will" they are unable to access.

If i removed BGP backdoor then "Cux" is able to access Will without any issues.


Can someone please help me how it can be solved? will route map help?


Thanks in advance...


Regards,
Naidu.

2 Accepted Solutions

Accepted Solutions

Hi,

my understanding is:

When you are are connecting from Cux to Will (without the backdoor command), the packet is sent:

Cux ---->Easy vpn---->DC---->MPLS---->Will

and when the reply packet is sent from Will to Cux, it takes

Will--->MPLS--->DC--->Easy vpn--->Cux path.

After adding the backdoor commands for DC and Will subnets, the packet takes

Cux ---->Easy vpn---->DC---->DMVPN---->Will but the reply still takes

Will--->MPLS--->DC--->Easy vpn--->Cux path.

This is what is called an asymmetric routing - packets are taking a different path when returning back.

IMHO, backdoor configured for Cux subnet in Will might help - causing the packets to pass the DMVPN on the way back to DC/Cux.

HTH,

Milan

View solution in original post

Hi Naidu,

well, it's a little risky to say "configure

router eigrp 200
redistribute bgp **AS** metric 100000 10000 255 1 1500

instead of

redistribute bgp **AS** metric 100000 10 255 1 1500"

I don't know your network details and can't see all possible consequences in your productive network.

But at least, that's something you might take into consideration, it should bring you EIGRP metric 2585600 insted of 28160 for the redistributed prefixes.

Again, out of business hours recommended for changes.

See also http://www.cisco.com/en/US/customer/tech/tk365/technologies_white_paper09186a0080094cb7.shtml#eigrpmetrics

or http://www.cisco.com/application/pdf/paws/16406/eigrp-toc.pdf for EIGRP metric details.

HTH,

Milan

View solution in original post

21 Replies 21

milan.kulik
Level 10
Level 10

Hi,

some kind of an asymmetric routing possibly?

Did a traceroute show something?

Traffic from Cux sent from DC to Will via DMVPN and back via MPLS, e.g.?

What about network ...backdoor configured in Will for the Cux subnets?

HTH,

Milan

some kind of an asymmetric routing possibly?
I didn't understand it

Did a traceroute show something?

Cux# pi 10.192.2.2 (DC)
10.192.2.2 is alive, time = 50 ms

Cux# pi 10.150.2.101 (Will)
10.150.2.101 is alive, time = 175 ms

Cux# tr 10.150.2.101 (Will)
traceroute to 10.150.2.101 ,
              1 hop min, 30 hops max, 5 sec. timeout, 3 probes
1 10.192.1.1             25 ms      25 ms      50 ms
2 10.246.122.10 (mpls)   25 ms      25 ms      25 ms
3  *  *  *
4  *  *  *

Cux# tr 10.192.2.2 (DC)
traceroute to 10.192.2.2 ,
              1 hop min, 30 hops max, 5 sec. timeout, 3 probes
1 10.192.2.2             50 ms      25 ms      25 ms

Traffic from Cux sent from DC to Will via DMVPN and back via MPLS, e.g.?

Traffic from Cux sent to DC via Easy vpn, from DC to Will via MPLS and back from (Will to DC) through DMVPN ---No problems
Packet send from Cux to Will:- (Cux ---->Easy vpn---->DC---->MPLS---->Will)
Packet received from Will to Cux:- (Will--->DMVPN--->DC--->Easy vpn--->Cux)

But when I changed it with BGP back door like....Traffic from Cux sent to DC via Easy vpn, from DC to Will via DMVPN (used backdoor) and back from (Will to DC) through DMVPN --- having problems

Packet send from Cux to Will:- (Cux ---->Easy vpn---->DC---->DMVPN---->Will)
Packet received from Will to Cux:- (Will--->DMVPN--->DC--->Easy vpn--->Cux)
I want this setup to be work without any problems


What about network ...backdoor configured in Will for the Cux subnets?
No, I have not configured back door for Cux subnet in Will
I have only configured back door for DC subnets (network 10.192.0.0 mask 255.255.255.0 backdoor)


Regards,
Naidu.

Hi,

my understanding is:

When you are are connecting from Cux to Will (without the backdoor command), the packet is sent:

Cux ---->Easy vpn---->DC---->MPLS---->Will

and when the reply packet is sent from Will to Cux, it takes

Will--->MPLS--->DC--->Easy vpn--->Cux path.

After adding the backdoor commands for DC and Will subnets, the packet takes

Cux ---->Easy vpn---->DC---->DMVPN---->Will but the reply still takes

Will--->MPLS--->DC--->Easy vpn--->Cux path.

This is what is called an asymmetric routing - packets are taking a different path when returning back.

IMHO, backdoor configured for Cux subnet in Will might help - causing the packets to pass the DMVPN on the way back to DC/Cux.

HTH,

Milan

Hi,

I also strongly believing that backdoor configured for Cux subnet in Will might help.

I will perform it when i get down time and update you...

Regards,

Naidu.

Hi Milan,

Hope you are doing well.

Now I have a problem with BGP backdoor command between DC and POL. These two sites are connected over MPLS and DMVPN (MPLS running BGP and DMVPN running EIGRP).

I used BGP backdoor at both ends to take the primary path on DMVPN.

Yesterday one of the BGP peer which is connected to DC had flapped and since then the primary path between DC and POL is taking on MPLS instead DMVPN (still BGP backdoor command is there at both ends as it is). Then I cleard BGP at my DC and then things working fine as it should but again since today morning it is same primary path taking on MPLS.

What could be the possible causes and how to fix this permanently.

Thanks in advance.

Regards,

Naidu.

Hi,

isn't there some mutual BGP/EIGRP redistribution problem?

My BGP netwok backdoor command understanding is as long as the EIGRP route is received, it beats the BGP route.

I could imagine some scenarios where your router flap could make the route disappear from EIGRP, and being redistributed from BGP to EIGRP somehow. And after the fix the EIGRP route might not win back for some reason.

This could happen in some more coplex topologies, I remember a case in the past where something similar happened - depending on the sequence od OSPF/BGP prefix disappearing the other one was winning.

So I'd recommend to check the redistribution points.

BR,

Milan

Hi Milan,

These are what the routing protocols and redistribution stuff configured at the DC device.

Note: From POL it is coming in DMVPN which should but the problem is while going back from DC--->POL is going on MPLS instead DMVPN

router eigrp 200
redistribute connected
redistribute static
redistribute bgp **AS** metric 100000 10 255 1 1500
redistribute ospf 200 metric 4000 100 1 255 1500
network 192.168.xx.0
network 192.168.xxx.0
no auto-summary
!
router ospf 100
log-adjacency-changes
network 192.168.xx.0 0.0.0.255 area 0
default-information originate
distance 115
!
router bgp ***AS***
no synchronization
bgp router-id 10.46.2.1
bgp log-neighbor-changes
bgp bestpath as-path ignore
bgp redistribute-internal
network 10.10.xx.0 mask 255.255.255.0
network 10.13.xx.0 mask 255.255.252.0 backdoor ---> POL subnet
network 10.28.0.0 mask 255.255.0.0
network 10.246.0.0 mask 255.255.0.0
redistribute connected
redistribute static
neighbor 10.246.xx.xx remote-as 1
neighbor 10.246.xx.xx soft-reconfiguration inbound
neighbor 10.246.xx.xx route-map MPLS in
neighbor 10.246.xx.xx route-map GREENLAND out
neighbor 192.168.xxx.xx remote-as ***AS***
neighbor 192.168.xxx.xx password 7 ******************

neighbor 192.168.xxx.xx update-source Vlan51
maximum-paths 3
no auto-summary

Regards,

Naidu.

Hi,

IMHO, the problem might be the metric you are using for BGP redistribution to EIGRP.

Can you try

sh ip eigrp topo  10.13.xx.0/22 (the POL subnet)

to check why you are not receiving a better route from your EIGRP?

BR,

Milan

Hi Milan,

Plase find the below required info...

#sh ip eig topology 10.13.xx.0/22
IP-EIGRP (AS 100): Topology entry for 10.13.xx.0/22
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 28160
  Routing Descriptor Blocks:
  10.246.xx.xx, from Redistributed, Send flag is 0x0
      Composite metric is (28160/0), Route is External
      Vector metric:
        Minimum bandwidth is 100000 Kbit
        Total delay is 100 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 0
      External data:
        Originating router is 192.168.xxx.x (this system)
        AS number of route is ***AS***
        External protocol is BGP, external metric is 0
        Administrator tag is 1 (0x00000001)
  192.168.xxx.xxx (Vlan999), from 192.168.xxx.xxx, Send flag is 0x0
      Composite metric is (1538816/1538560), Route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 50110 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1400
        Hop count is 2

I thought to clear bgp in the DC to just solve the issue temperarly... But it gives me some options which are below, which one should i apply to clear the BGP.

#clear bgp ?
  all    All address families
  ipv4   Address family
  ipv6   Address family
  vpnv4  Address family

#clear bgp all ?
  <1-65535>     Clear peers with the AS number
  peer-group    Clear all members of peer-group
  update-group  Clear all members of update-group

#clear bgp all ***AS***

Thanks in advance.

Regards,

Naidu.

Hi,

yeah, that's what I was afraid of:

You are receiving the POL prefix via EIGRP from 192.168.xxx.xxx, Composite metric is (1538816/1538560)

But at the same time you are redistributing it from BGP with better metric:

10.246.xx.xx, from Redistributed, Composite metric is (28160/0)
Originating router is 192.168.xxx.x (this system)

IMHO, you need to change the EIGRP metric you are using for BGP redistribution to EIGRP to make the metric worse (higher) than the metric you are receiving from EIGRP.

You could use a route-map to specify different metrics for particular prefixes, if necessary.

To fix temporarily, my favorite command is

clear ip bgp * soft

If supported by IOS, that should force all the peers to resend the BGP updates without shutting down the peering.

But sometimes (when complicated redistributions are used, e.g.) it does not help and you need to use

clear ip bgp *

for a hard BGP session reset.

Of course, out of business hours is recommended for such a clearing.

BR,

Milan

Hi Milan,

The 192.168.xxx.x is the router in DC where Internet is terminated and DMVPN is configured and EIGRP is the protocol is running.
When I say network ***POL subnet*** backdoor in 10.246.xx.xx backdoor (where mpls defined and BGP is running) then it has to go through 192.168.xxx.x to DMVPN tunnel.


***********IMHO you need to change the EIGRP metric you are using for BGP redistribution to EIGRP to make the metric worse (higher) than the metric you are receiving from EIGRP.
You could use a route-map to specify different metrics for particular prefixes, if necessary.**********

Could you please give me the correct configure that to change the EIGRP metric and regarding route-map is not necessary for now.

I have provided the EIGRP & BGP configuration with redistribution in my previous post.

Thanks in advance.

Regards,
Naidu.

Hi Naidu,

well, it's a little risky to say "configure

router eigrp 200
redistribute bgp **AS** metric 100000 10000 255 1 1500

instead of

redistribute bgp **AS** metric 100000 10 255 1 1500"

I don't know your network details and can't see all possible consequences in your productive network.

But at least, that's something you might take into consideration, it should bring you EIGRP metric 2585600 insted of 28160 for the redistributed prefixes.

Again, out of business hours recommended for changes.

See also http://www.cisco.com/en/US/customer/tech/tk365/technologies_white_paper09186a0080094cb7.shtml#eigrpmetrics

or http://www.cisco.com/application/pdf/paws/16406/eigrp-toc.pdf for EIGRP metric details.

HTH,

Milan

Hi Milan,

Alright, I will try and check with the given metrics.

And the give url by you is not accessible for my logins it is saying....

***The file or application you are trying to access may require additional entitlement or you are trying to access a file with an invalid name. Additional entitlement levels are granted based on a users relationship with Cisco on a per-application basis.***

Is there any other urls where I can check about the correct metrics..

Thanks in advance.

Regards,

Naidu.

Hi,

the second URL should be available without CCO login, I hope.

If not, try to search "EIGRP metric formula" or "EIGRP metric calculation" on Cisco web pages.

BR,

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: