advertise the routes learned by eigrp into bgp

[Ali Alshehri]

Hi Guys,

    I have a small question, i have two Routers each is connected to a different  ISP. each router is connected through a different BGP. The two routers are connected to one Core switch and eigrp is connecting them all. My problem is that locations from sites connected through ISP 1 can not reach to sites connected to ISP 2, but all are there in the Core Switch. I know that there is a way to make it happen to reach each other but i don't know how.

below is the configuration from all:

1 - Router 1:

router eigrp 1
 network 128.1.8.0 0.0.7.255
 redistribute bgp 64551 metric 100 1 255 1 1500
!
router bgp 64551
 bgp log-neighbor-changes
  redistribute static route-map redistribute-list
 redistribute eigrp 1
 neighbor X.X.X.Xremote-as 65000

2- Router 2:

router eigrp 1
 redistribute bgp 65000 metric 100 1 255 1 1500
 no auto-summary
!
router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 redistribute connected
 redistribute eigrp 1
 neighbor X.X.X.X remote-as 35819
 no auto-summary

3- Core Switch:

router eigrp 1
 network 10.100.0.0 0.0.255.255
 network 128.1.8.0 0.0.7.255
 network 172.16.0.0 0.0.3.255
 eigrp stub connected summary

Please advise?

Kind regards,

Ali

[Peter Paluch]

Ali,

Because your Core switch is configured as an EIGRP stub router, its behavior changes from a normal EIGRP router. Among other things, an EIGRP stub router never advertises routes that are learned via EIGRP themselves. In other words, the Core switch learns about EIGRP networks but it does not propagate them further because the stub functionality prevents it from doing so.

I do not recommend changing this setting without first understanding why the Core switch was configured as a stub. In addition, considering that you are basically considering leaking routes from ISP1 to ISP2 and vice versa, I am very much against doing so until we all better understand your network design and needs. I am not sure if you are in charge of the design of this network but if not, your designer should be contacted first. Doing hasty redistribution here and there could screw up things badly.

In any case, it would be helpful if you posted a rather detailed diagram of your entire network including the ISPs and the sites, including the addressing plan and an explanation of why are things done this way in the first place. You understand that the changes you propose can have a big impact on the operability of your network and we do not want to do anything without properly understanding its consequences.

Just wondering - are you using any kind of VPN over those ISPs?

Best regards,
Peter

[Ali Alshehri]

Hi Peter, 

    Thank you for checking out my case.. I have actually taken over the responsibility of this network, the old guy left the company before I joined. 

The current design for the core is collapsed core so there is no distribution layer. All the access switches are connected to the core, as well as the firewall and the two Routers I mentioned earlier.  As for the ip addressing, it used to be from a public range and I'm slowly changing them to a privet addresses.

As for the ISP connection it is MPLS (ip-vpn) 

My question, if I removed the stub configuration will it solve my issue and what it could be the worst scenario. 

Thanks again 

Ali

[Ali Alshehri]

One more thing for the setup, actually it used to be one ISP, and now we are migrating to a different ISP slowly, that's why I need to reach the site from the other ISP sites. 

[Peter Paluch]

Ali,

As I do not know your network and you have not posted any diagram, I can only guess.

If you remove the EIGRP stub configuration from the Core switch, your EIGRP neighborship will flap and will be reestablished - this may cause a transient connectivity outage in your network. However, it will allow the Core router to advertise all routes it has learned via EIGRP itself. This should allow the routers Router1 and Router2 to learn about each of their own routes and redistribute them further.

It is hard to comment on the worst case scenario without knowing your network. In general, however, your sites may begin to route to each other over the VPN instead of some direct connection between them, if there is any. Also, depending on what addresses are being used, the public ranges may start appearing as reachable over the VPN instead of the public internet. Whether this is good or bad depends on you. Generally speaking, by doing the redistribution, you will introduce new reachability information into the VPN that has not existed there before, and some routing may be affected. Obviously, I cannot say nothing more specific.

Best regards,
Peter

[Ali Alshehri]

Hi Peter,

     thank you very much for the information you provided. I was wondering earlier why it did not work with me when i configured the Router 2.. Anyway it is still fixed my issue as i could not remove the Stub configuration there because it can not be removed (licensee issue i guess). So mostly i have to go with stub  leak-map is that true?

Kind Regards,

Ali

[Peter Paluch]

Hello Ali,

I see - the stub configuration is there probably because of IP Base license.

I believe that a better solution in this case would be to avoid redistributing EIGRP back into BGP, and instead, configure a BGP peering between your routers Router1 and Router2. This BGP peering will allow these two routers to learn about the networks in each of the VPNs. The redistribution from BGP to EIGRP should still be configured as it is now to allow your Core switch to learn about all networks in both VPNs.

You have to keep in mind that your two BGP routers are in different autonomous systems. As such, you will need to configure a eBGP multihop session, allowing the routers to establish an external BGP adjacency even though they are not directly connected (I assume that the two routers are not in the same internal subnet).

Best regards,
Peter