×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

BGP backdoor

Answered Question
Nov 2nd, 2010
User Badges:
  • Blue, 1500 points or more

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.

Correct Answer by milan.kulik about 6 years 9 months ago

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

Correct Answer by milan.kulik about 6 years 9 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
milan.kulik Tue, 11/02/2010 - 02:20
User Badges:
  • Red, 2250 points or more

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

Latchum Naidu Tue, 11/02/2010 - 03:42
User Badges:
  • Blue, 1500 points or more

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.

Correct Answer
milan.kulik Tue, 11/02/2010 - 04:02
User Badges:
  • Red, 2250 points or more

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

Latchum Naidu Wed, 11/03/2010 - 01:14
User Badges:
  • Blue, 1500 points or more

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.

Latchum Naidu Tue, 11/23/2010 - 06:07
User Badges:
  • Blue, 1500 points or more

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.

milan.kulik Tue, 11/23/2010 - 06:53
User Badges:
  • Red, 2250 points or more

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

Latchum Naidu Wed, 11/24/2010 - 06:52
User Badges:
  • Blue, 1500 points or more

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.

milan.kulik Wed, 11/24/2010 - 07:27
User Badges:
  • Red, 2250 points or more

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

Latchum Naidu Wed, 11/24/2010 - 23:15
User Badges:
  • Blue, 1500 points or more

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.

milan.kulik Wed, 11/24/2010 - 23:50
User Badges:
  • Red, 2250 points or more

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

Latchum Naidu Thu, 11/25/2010 - 00:04
User Badges:
  • Blue, 1500 points or more

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.

Correct Answer
milan.kulik Thu, 11/25/2010 - 00:54
User Badges:
  • Red, 2250 points or more

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

Latchum Naidu Thu, 11/25/2010 - 01:41
User Badges:
  • Blue, 1500 points or more

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.

milan.kulik Thu, 11/25/2010 - 01:55
User Badges:
  • Red, 2250 points or more

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

Latchum Naidu Mon, 12/06/2010 - 01:58
User Badges:
  • Blue, 1500 points or more

Hi Milan,


Hope you are doing well...


Yesterday I had down time from my customer and have changed the Metric (BGP redistribution in EIGRP) but no luck.

I have cleared BGP also after done this... But still primary path is taking over MPLS only...

Can you please give me any other suggestions and let me know if you need any info for your further investigation.



Regards,

Naidu.

milan.kulik Mon, 12/06/2010 - 02:13
User Badges:
  • Red, 2250 points or more

Hi Naidu,


can you provide

sh ip eig topology 10.13.xx.0/22

agian, together with sh ip bgp 10.13.xx.0/22

?


BR,

Milan

Latchum Naidu Mon, 12/06/2010 - 03:01
User Badges:
  • Blue, 1500 points or more

Hi Milan,


Please find the below required info.



#sh ip eig topology 10.13.96.0/22
IP-EIGRP (AS 100): Topology entry for 10.13.96.0/22
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1538816
  Routing Descriptor Blocks:
  192.168.199.xx (Vlan999), from 192.168.199.xx, 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


#sh ip bgp 10.13.96.0/22
BGP routing table entry for 10.13.96.0/22, version 83
Paths: (2 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))
Multipath: eBGP
  Advertised to update-groups:
     1
  1 65000 11
    10.246.2.xx from 10.246.2.xx (192.168.9.93)
      Origin incomplete, localpref 200, valid, external, best
  1 65000 11, (received-only)
    10.246.2.xx from 10.246.2.xx (192.168.9.93)
      Origin incomplete, localpref 100, valid, external



Regards,

Naidu.

milan.kulik Mon, 12/06/2010 - 03:21
User Badges:
  • Red, 2250 points or more

Hi,


it looks OK to me now!


As you can see you are not redistributing the prefix to EIGRP now, you are receiving it from the EIGRP neighbor only!

And the BGP entry is failing to write to the RIB which is also correct.


So what's wrong?

What does the sh ip route  10.13.96.1 (or some other living host in the subnet) display?

Isn't there some  more specific prefix present?


BR,

Milan

Latchum Naidu Mon, 12/06/2010 - 04:05
User Badges:
  • Blue, 1500 points or more

Hi Milan,


My appologies, its my wrong check.

The delay change in BGP redistribution into EIGRP worked out.


Thanks again.

Regards,

Naidu.

Latchum Naidu Sun, 12/12/2010 - 23:28
User Badges:
  • Blue, 1500 points or more

Hi Milan,


After I changed the delay on bgp redistribution into eigrp it worked fine.

But yesterday we have that EIGRP neighbor (POL) has flapped and since then the primary path is taking over MPLS instead DMVPN.


Can you please tell me what is the necessary action to get it stable on dmvpn only in any case.


Please find the below eigrp and bgp topology info for POL subnet...


#sh ip eig to
DK-DATACENTER-CORE01#sh ip eig topology 10.13.96.0/22
IP-EIGRP (AS 100): Topology entry for 10.13.96.0/22
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 512000
  Routing Descriptor Blocks:
  10.246.2.xx, from Redistributed, Send flag is 0x0
      Composite metric is (512000/0), Route is External
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 10000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 0
      External data:
        Originating router is 192.168.199.1 (this system)
        AS number of route is 65100
        External protocol is BGP, external metric is 0
        Administrator tag is 1 (0x00000001)
  192.168.199.xx (Vlan999), from 192.168.199.xx, 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


1#sh ip bgp 10.13.96.0/22
BGP routing table entry for 10.13.96.0/22, version 175
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Multipath: eBGP
  Advertised to update-groups:
     1
  1 65000 11
    10.246.2.10 from 10.246.2.10 (192.168.9.93)
      Origin incomplete, localpref 200, valid, external, best
  1 65000 11, (received-only)
    10.246.2.10 from 10.246.2.10 (192.168.9.93)
      Origin incomplete, localpref 100, valid, external

Regards,

Naidu.

milan.kulik Mon, 12/13/2010 - 02:33
User Badges:
  • Red, 2250 points or more

Hi Naidu,


1) looking to your output, I see

#sh ip eig to
DK-DATACENTER-CORE01#sh ip eig topology 10.13.96.0/22
IP-EIGRP (AS 100): Topology entry for 10.13.96.0/22
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 512000
Routing Descriptor Blocks:
10.246.2.xx, from Redistributed, Send flag is 0x0
Composite metric is (512000/0), Route is External
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 10000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 0
External data:
Originating router is 192.168.199.1 (this system)
AS number of route is 65100
External protocol is BGP, external metric is 0
Administrator tag is 1 (0x00000001)
192.168.199.xx (Vlan999), from 192.168.199.xx, 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


Which IMHO seems like this router is using

redistribute bgp **AS** metric 10000 1000 255 1 1500

instead of

redistribute bgp **AS** metric 100000 10000 255 1 1500


2) Another problem might be:

Due to better administrative distance, whenever an eBGP prefix comes, it beats the same prefix received from EIGRP on your router.

You need to clarify what you want and possibly modify the AD for EIGRP (or some prefixes only?).

Don't forget when configuring mutual redistribution, it's sometimes important to think about the possible sequence the same prefix comes (what happens when it comes from BGP first and then from EIGRP or vice versa first from EIGRP and from BGP then?).

See also this thread:  https://supportforums.cisco.com/message/3242635#3242635


BR,

Milan

Actions

This Discussion