Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

EBGP peering question.

Hi All,

2 Core devices (6500 acting as L3/L2 core and both connected via Etherchannel)

One of the core is having ebgp with satellite office rtr. Satellite office rtr also running with OSPF via T1 (different link than BGP) to Core devices location. OSPF is main protocol.

Inorder for the second core device to reach the satellite office via BGP than OSPF, what is the recomended config..?

1. Establish another EBGP session from 2nd Core device to the Satellite office router and redistribute BGP in to OSPF (just as done on 1st core device)..?

(In this case as core 1 advertising internal networks to satellite office via BGP, do I still need to

advertise same n/w from core as well to satellite office..?)

2. Establish ebgp between both core devices (there is no BGP on core2 at this time) and redistribute to OSPF, so that 2nd core learn & prefer satellite office networks via BGP from Core1 (than OSPF).

Thank you in advance

MS

14 REPLIES
Cisco Employee

Re: EBGP peering question.

Hi,

Let's say CORE-1 has an eBGP session with the remote office router called RTR.

If I understand correctly:

- CORE-1, CORE-2 and RTR are in the same OSPF domain

- CORE-1 also has an eBGP session with RTR

- CORE-1 redistributes BGP learned prefix into OSPF

As a result, CORE-2 has a choice between OSPF routes from RTR and CORE-1 but currently prefers RTR OSPF route

You would like CORE-2 to use CORE-1 OSPF routes right ?

If the above assumptions are correct, it depends how RTR announces its routes into OSPF. If CORE-2 sees RTR routes as Inter- or Intra-area, there is nothing we can do at the OSPF level as OSPF will always prefer those routes to an External one.

If you build an iBGP session between CORE-1 and CORE-2, it will learn RTR prefixes from BGP and then you just need to decrease BGP administrative distance on CORE-2 down to 109 (at least) so the BGP route will be prefered over the OSPF one's.

HTH

Laurent.

Blue

Re: EBGP peering question.

Laurent:

I understood his concerns the way you did, except for one thing: I think he wants CORE 2 to use BGP routes instead of OSPF.

I also think CORE 2 is learning OSPF from RTR and CORE 1, so, as far as manipulating OSPF is concerned, it's just as you said regarding external routes, etc.

But I dont think he cares about that. I think he wants BGP to be used, so your final paragraph about iBGP is what , I think, he is looking for.

Victor

Re: EBGP peering question.

Thank you both for your time and suggestions.

"I think he wants CORE 2 to use BGP routes instead of OSPF." --> This is correct.

First I thought of IBGP between Core1 & 2 but as cisco docs does not recomend changing the default distance -kind of stuck there.

So On core1:

rtr brp 65110

neighbor remote-as 65110

neighbor remote-as 65530

neighbor nexthop-self

network 192.168.110.0

Core2:

rtr brp 65110

neighbor remote-as 65110

distance 20 105 200

Will the above config is enough..? So that Core1 sends the BGP routes to Core2?

TIA

MS

Cisco Employee

Re: EBGP peering question.

With this configuration, CORE-2 will receive 192.168.110.0 and eBGP routes learned by CORE-1 from Satellite RTR and set and AD of 105. As a result, if CORE-2 learned the same prefixes from OSPF, the iBGP routes will be prefer.

You don't need the nexthop-self as it's already an eBGP session

HTH

Laurent.

Re: EBGP peering question.

Hi Laurent,

You mentioned a great point - "CORE-2 will receive 192.168.110.0"

Core 1 & Core 2 are redundant L3 switches each with different Vlan interface with HSRP configured for each VLan subnet and 192.168.110.0 is one of the server subnet residing locally on 1&2. For Ex: On Core1 (vlan110: 192.168.110.2) and Core2 (vlan110 : 192.168.110.3& Standby ip: 192.168.110.1). So receiving the server subnet again from IBGP does not cause any routing issues as it is direclty connected. below is o/p currently on S2:

******************************

Core-S2#sh ip route 192.168.110.0

Routing entry for 192.168.110.0/24

Known via "connected", distance 0, metric 0 (connected, via interface)

Redistributing via ospf 100

Advertised by ospf 100

Routing Descriptor Blocks:

* directly connected, via Vlan110

Route metric is 0, traffic share count is 1

***************************************

Thank you

MS

Hall of Fame Super Silver

Re: EBGP peering question.

Hello Mehboob,

modifying AD can have an impact in the future.

I would use an eBGP multihop session between satellite router and Core2 so that Core can compare between an eBGP route and an OSPF route.

This leaves you open to use iBGP in the future between Core1 and Core2 and other routers if needed.

Hope to help

Giuseppe

Re: EBGP peering question.

Hi Giuseppe,

Thank you for your suggestion. So if I form ebgp with the Satellite router from Core2... As Core1 is already advertising the necessary server Subnets to Satellite office rtr, in the Core2 ebgp config I do not need to advertise the same servicer subnets again. Is that correct?

Thank you

MS

Hall of Fame Super Silver

Re: EBGP peering question.

Hello Mehboob,

being on the path to Core1 traffic from satellite router will never come back to Core2, so this is without any practical effects return traffic will always be via Core1 unless Core1 loses connections to server subnets.

But if using network commands under BGP (or redistribute OSPF) Core1 will keep advertise server subnets on the eBGP session, until it sees them in OSPF via Core2 even if not directly connected anymore.

Hope to help

Giuseppe

Re: EBGP peering question.

Thank you again Guiseppe. So if I choose to go with EBGP...

*****************************

Core1: existing in prod

rtr brp 65110

neighbor <10.50.25.1> remote-as 65530

neighbor <10.50.25.1> nexthop-self

neighbor <10.50.25.1> ebgp-multihop 4

network 192.168.110.0

Core2:

rtr brp 65110

neighbor <10.50.25.1> remote-as 65530

neighbor <10.50.25.1> nexthop-self

neighbor <10.50.25.1> ebgp-multihop 4

network 192.168.110.0

Satellite office:

rtr brp 65530

neighbor <192.168.20.1> remote-as 65110

neighbor <192.168.20.1> nexthop-self

neighbor <192.168.20.1> ebgp-multihop 4

neighbor <192.168.20.2> remote-as 65110

neighbor <192.168.20.2> nexthop-self

neighbor <192.168.20.2> ebgp-multihop 4

network 10.50.25.0

network 10.50.50.0

10.50.25.1: Satellite office rtr bgp-id

192.168.20.1: Core1 bgp-id

192.168.20.2: Core2 bgp-id

************************************

The above config is sufficient. is that correct.?

TIA

MS

Hall of Fame Super Silver

Re: EBGP peering question.

Hello Mehboob,

nexthop-self is not needed it is already updated on eBGP sessions.

the ebgp-multihop parameter has to be tailored to your needs (if there are routers in the middle they need to be able to route traffic).

if I understand your setup you want to build two eBGP sessions with two ip addresses (in the same vlan ?)

if so you can advertise the server subnets also on Core2 and satellite router can use

maximum-paths 2

to install both routes and so you can get load balancing.

Hope to help

Giuseppe

Re: EBGP peering question.

Thanks again Giuseppe. My case here both at Core location and Satellite office the BGP uses only one exit path , So Iam not sure if 'maximum-path' command really helps here. I will update after ebgp config implemention.

Thank you

MS

Re: EBGP peering question.

Hi all,

Created parallel EBGP session and everything working fine at this time. Thank you all for your suggestions and time.

rgds

MS

Cisco Employee

Re: EBGP peering question.

You're right and as a result you will see the subnet in Rib-Failure mode in the BGP table because it is selected as best from BGP but can't be inserted in the RIB as we have a better choice from another routing protocol (directly connected in this case)

Laurent.

New Member

Re: EBGP peering question.

please can you response to Internet gateways design issues, questions.

190
Views
14
Helpful
14
Replies