04-16-2009 07:22 AM - edited 03-04-2019 04:23 AM
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
04-16-2009 09:51 AM
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.
04-16-2009 10:01 AM
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
04-16-2009 10:46 AM
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
neighbor
neighbor
network 192.168.110.0
Core2:
rtr brp 65110
neighbor
distance 20 105 200
Will the above config is enough..? So that Core1 sends the BGP routes to Core2?
TIA
MS
04-16-2009 11:11 AM
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.
04-16-2009 11:36 AM
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
04-16-2009 11:55 AM
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
04-16-2009 12:05 PM
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
04-16-2009 12:36 PM
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
04-17-2009 11:33 AM
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
04-18-2009 10:34 AM
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
04-20-2009 08:14 AM
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
04-30-2009 11:17 AM
Hi all,
Created parallel EBGP session and everything working fine at this time. Thank you all for your suggestions and time.
rgds
MS
04-16-2009 11:56 AM
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.
04-16-2009 11:49 AM
please can you response to Internet gateways design issues, questions.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: