EIGRP\BGP redistribution issue

Roman Pomazanov · ‎09-11-2015

Hi dear, colleagues.

I have small (as I hope) questions according redistribution between BGP and EIGRP protocols. I’ve attached scheme to this post. Please look at it and read describing.

I have three sites. On the first one I have internal networks behind my Internal Router 1 which is distributing to Edge Router1 via EIGRP.

On the second site I also have internal networks behind my Internal Router2 which is distributing to Edge Router2 via iBGP

Both of this sites connected to ISP MPLS using eBGP and exchange routes through it. Noting that both Edge routes has outbound filter in ISP direction and announce to them only internal routes.

As backup for ISP MPLS I use IPSEC tunnel via Internet with EIGRP. For interaction I have to use redistributing on Site1 and Site2 from BGP to EIGRP.

On the Site1:

router eigrp 1

 redistribute bgp 64500 metric 10000 0 255 1 1

On Site2:

router eigrp 1

redistribute bgp 64516 metric 100000 0 255 1 1

And also for redistributing from EIGRP to BGP on both site a have in my BGP configuration string

  redistribute eigrp 1 (without any filters)

Through via IPSEC tunnel I have BGP session from Site 1 to Site3 and distribute there Site 1 internal networks without any outbound\redistribute filters.

So in normal situation from my point of view I should have follow behavior:

EdgeRouter1 (ER1) receive announce about Site1 internal networks from Internal Router1 (IR1) via EIGRP. Then redistribute them via eBGP to ER3 directly and to ER2 via ISP MPLS. Also distribute them to ER2 via EIGRP over IPSEC.

ER2 have two ways for Site1 internal networks – via EIGRP to IPSEC tunnel and via eBGP to ISP MPLS. ER2 chose BGP because eBGP has less AD. Then ER2 announce networks to IR2 via iBGP

And this works fine here. All looks good.

From other side:

ER2 receive announce about Site2 internal networks from IR2 via iBGP. Then renounce them to ISP via eBGP and also send announce via EIGRP

ER1 also should have two way for Site2 internal networks – via eBGP and via EIGRP. And ER1 should chose the BGP one, but it doesn’t happens – it chose EIGRP.

And I don’t know why…

I suggest that’s something wrong with EIGRP to BGP redistribution from Site1 side, because when I execute no redistribute eigrp 1 everything returned to normal.

Here some diagnostic

show bgp summary

show me two bgp neigbors – CPE of ISP and ER3

show ip eigrp neigbors

show me two eigrp neigbors – IR1 and ER2

If I try to show bgp I see than I have two BGP way to prefix:

     Network          Next Hop            Metric LocPrf Weight Path

 *>  172.16.0.0/24     172.30.252.9       1305600         32768 ?

 *                   172.31.254.100                             0 65001 [AS path in MPLS] 64516 ?

172.30.252.9 – loopback of ER2 (eigrp neigbor)

172.31.254.100 – IP address of ISP CPE (bgp neigbor)

Why the first one is marked as best? And why EIGRP route goes to routing table instead eBGP?

ssherman68 · ‎09-11-2015

Warning. I did not take a close look at this. But since no one else answered, look up BGP synchronization. Maybe it's got something to do with that?

Rolf Fischer · ‎09-12-2015

Hi Roman,

although your explanation is very detailed, I'm not sure if I understood everything correctly.

I think what happends is this:

Let's assume ER1 learnes a prexif located at site 2 first via EIGRP. It installs an external EIGRP route and redistributes it into BGP. Result in the BGP table:

 *>  172.16.0.0/24     172.30.252.9       1305600         32768 ?

If now the BGP peering is established as well, the same prefix is learned via eBGP:

*                   172.31.254.100                             0 65001 [AS path in MPLS] 64516 ?

The default AD of a eBGP route is 20 whereas the EIGRP route in the routing table has an AD of 170. However, from a BGP perspective, router ER1 considers itself as the originator of that route, so by default it sets the Weight of that route to 32768 and considers it as best here.

Perhaps this could be solved by simply increasing the Weight of the eBGP-learned routes (*), but I believe it would be easier and more predictable to use BGP for the IPSec/Internet backup path as well. Is there a particular reason why you use EIGRP here?

One more note: At site 2 you may run into routing loops when the originally iBGP-learned routes (AD 200) are reflected back from site 1 via external EIGRP (AD 170).

HTH

Rolf

(*): I strongly recommend to test this first in a lab environment!

Roman Pomazanov · ‎09-14-2015

Hi Rolf, thank for your reply.

I know that using uniformed routing protocol is more preferable in any case, but at this moment i have that i have. I'm only try to find out reasons of such behavior.

Actually i drew only part of my big network :) In posting this message, I was hoping that my problem is very simple and i just missed the obvious details.But it seems it is not so simple...

So, i've update my scheme and you can find find it in attache.

I'v added another one site (number 4) which have the same topology as Site1 - it also connected to IPS MPLS via eBGP, has EIGRP as internal routing protocol and also have IPSEC tunnels with EIGRP for backup. The only difference - there are no any redistribution from EIGRP to BGP - only network command in BGP settings.

And for Site4 networks i see fully expected behavior.

Prefix putted into routing table from BGP:

sh ip ro 172.30.0.1
Routing entry for 172.30.0.0/22
  Known via "bgp 64500", distance 20, metric 0
  Tag 65000, type external
  Redistributing via eigrp 1
  Advertised by eigrp 1 metric 10000 0 255 1 1
  Last update from 172.31.254.100 5w4d ago
  Routing Descriptor Blocks:
  * 172.31.254.100, from 172.31.254.100, 5w4d ago

In show bgp command i see this prefix only from my BGP neighbor -no from EIGRP as for Site2:

sh bgp | i 172.30.0.0/22
 *>  172.30.0.0/22    172.31.254.100                       0 65000 [MPLS AS Path] 65009 i

But it exist in EIGRP topology as follows:

sh ip eigrp topology 172.30.0.0/22
EIGRP-IPv4 Topology Entry for AS(1)/ID(172.30.252.36) for 172.30.0.0/22
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 256000
  Descriptor Blocks:
  172.31.254.100, from Redistributed, Send flag is 0x0
      Composite metric is (256000/0), route is External
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 0 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 0
        Originating router is 172.30.252.36
      External data:
        AS number of route is 4779
        External protocol is BGP, external metric is 0
        Administrator tag is 65000 (0x0000FDE8)

 172.30.252.101 (Tunnel10), from 172.30.252.101, Send flag is 0x0
      Composite metric is (1290496/10496), route is External
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 50310 microseconds
        Reliability is 255/255
        Load is 15/255
        Minimum MTU is 1438
        Hop count is 2
      External data:
        Originating router is 172.30.255.116  
        AS number of route is 0
        External protocol is Static, external metric is 0
        Administrator tag is 0 (0x00000000)

The main difference between Site2 and Site4, that in Site2 i use iBGP for internal routing while on Site4 i use EIGRP.

So i think the main problem is in Site2 redistribution settings. But i have no idea what i need to check\fix.

Any new ideas? :)

Roman Pomazanov · ‎09-16-2015

It's look like the problem was resolved after i apply route my to redistribute eigrp 1 string and setting up less local-pref there

Rolf Fischer · ‎09-16-2015

Hi Roman, sorry for the late response; at the moment I've to work on some challenging own projects as well ;-)

I have to admit that it's not easy for me to understand what exactly is happening at your edge routers. The fact that no one of the routing experts (I'm certainly not on of them) here at CSC has joined the discussion so far tells me that others have difficulties too.

For example, I don't understand how you could solve the problem with lessening the Local Preference, when Weight has preference over LP in the BGP route selection process. Have you already done failover tests? If so, are the routing decisions deterministic? I still believe that, at least in the scenario of your first post (mutual redistribution at two edges), it depends on which routes are learned first.

Please keep us up to date if the problems remain, I'd really like to set up a gns3 lab as soon as I find the time.

Roman Pomazanov · ‎09-17-2015

Hi Rolf. Sure, I forgot mention that with less local-pref i use set weigh 0 as well.

And yes, i've done some redundancy test - i shut down exterrnal bgp session in Site2 and got connectivity via EIGRP.

From my POV this is only workaround while i'm trying to find reasons of such behavior