Dual Link EBGP with OSPF and EIGRP, but no IBGP

[Rick_Dees]

Hi Everyone - thanks for taking a look.

I have a conundrum.. I have the following situation (refer to diagram below);

I am joining 2 different networks (blue and green), both are private networks. The green network internal routing is done by OSPF. The blue network internal routing is done by EIGRP.

I am needing to join these 2 networks together, For particular reasons, this needs to be done via BGP.

In the green network, Routers A and B are geographically separate, with no direct connection between them, apart from learning routes via the internal network. The same goes for routers C and D in the blue network.

Question is;

What would be the best way to configure the BGP links?

Should routers A and B be in the same ASN?

Should Routers C and D be in the same ASN?

Should Routers A, B, C & D all be in different ASN's?

What is the best way to configure BGP, so that I don't get asymmetric routing?

Obviously, Routers A and B are going to learn the same routes from the green network, as C and D will learn the same routes from the Blue network. So the internal routers would learn the same route via the 2 bgp paths.

I can't set up iBGP in the blue or green network due to the amount of routers that are running in each network. So routers A and B will be doing a redistribution of BGP <-> OSPF, and routers C and D will be doing a redistribution of BPG <-> EIGRP.

All the networks in the green network need to be distributed to the blue network, and all networks in the blue network need to be distributed to the green network.

Is it a matter of just weighting the redistribution? and just have 2 bgp links?

There is no overlap of address space, so no need to perform any nat'ing

The 2 links is more for redundancy, rather than load sharing.

Hope someone can assist with the best path forward (excuse the pun!)

Thanks in advance!

[Giuseppe Larosa]

Hello @Rick_Dees ,

>> Should routers A and B be in the same ASN?

yes for example AS 65001

>> Should Routers C and D be in the same ASN?

yes for example AS 65002

>> Should Routers A, B, C & D all be in different ASN's?

RA and RB in same ASN and RC and RD in a different ASN ( the same for RC and RD)

>> What is the best way to configure BGP, so that I don't get asymmetric routing?

You would need iBGP sessions between RA,RB and between RC.RD to handle this only at BGP level.

>>

Is it a matter of just weighting the redistribution? and just have 2 bgp links?

There is no overlap of address space, so no need to perform any nat'ing

The 2 links is more for redundancy, rather than load sharing.

Let us assume that RA-RC is primary both directions how to achieve this?

the seed metric used in redistribution of BGP routes into OSPF in RA must be lower then the one used on RB.

The same in EIGRP on RC and RD with the special care that EIGRP seed metric has 5 components.

Now, depending on the size of the two networks you could use network commands in BGP to avoid mutual redistribution of BGP into OSPF and of OSPF into BGP and on RC.RD the same reasoning could be applied to EIGRP.

Otherwise if mutual redistribution is needed it should happen in a controlled way using route tags on the IGP side.

route-map BGP-to-OSPF-RA deny 10

match tag 51

route-map BGP-to-OSPF-RA permit 20

set metric 50

set tag 51

set metric-type 1

router ospf 10

redistribute bgp 65001 subnets route-map BGP-to-OSPF-RA

on RB:

route-map BGP-to-OSPF-RB deny 10

match tag 51

route-map BGP-to-OSPF-RB permit 20

set metric 500

set tag 51

set metric-type 1

router ospf 10

redistribute bgp 65001 subnets route-map BGP-to-OSPF-RB

for BGP you can enable auto-summary so that with a few network commands you cover each subnet in network A

RA:

router bgp 65001

auto-summary

network 10.0.0.0

neighbor 192.168.1.2 remote-as 65002

The combination to allow auto-summary and the network 10.0.0.0 will allow all connected or OSPF prefixes in 10/8 to be advertised without the need for redistribution of OSPF into BGP.

Edit : matching on route tags on BGP routes may be not supported. So I will review the route-map

The same can be done on RB

If network B uses a different major network you are fine. And you can use this approach also on RC, RD

on RC

router eigrp 65002

network 172.16.0.0

default-metric 10000 10 1 1 1500

redistribute bgp 65002 route-map BGP-into-EIGRP-RC

router bgp 65002

auto-summary

network 172.16.0.0

neighbor 192.168.1.1 remote-as 65001

Hope to help

Giuseppe

[Rick_Dees]

Thanks Giuseppe,

In regards to IBGP internally to both RA<->RB and RC<->RD. Generally don't you need to configure IBGP on all the routers within the domain to avoid potential looping?

I can't add IBGP to all the routers in the domain, as there are too many of them, and i can't change the configuration on all of them.

[Giuseppe Larosa]

Hello @Rick_Dees ,

I understand your point.

The only suggestion I can give you is to use network commands in BGP instead of mutual redistribution.

If this is feasible you can have a moderate complexity in the solution.

If for any reasons you go for mutual redistribution you should follow the configuration examples I have provided in my previous post: having two mutual redistribution points in each domain will need special care like use of route tags on IGP and BGP community in BGP.

When redistributing OSPF into BGP you can set a BGP community value like 65001:10 and then you can deny all BGP routes with that BGP community from being re-injected into OSPF.

The same idea can be applied on the EIGRP domain by setting a BGP community like 65002:65002 for EIGRP routes injected into BGP and then denying those BGP routes with that community value from being re-injected into EIGRP.

To make this to work your eBGP sessions need to have the command

neighbor x.x.x.x send-community.

For the other direction IGP to BGP you can use route-tags with the same logic.

Hope to help

Giuseppe

[pman]

Hi,
Attaches an example of redistribution using tags:

https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/8606-redist.html#ex2