OSPF eBGP connectivity

[NInja Black]

Hi,

 I have 5 routers in GNS3 in linear connection.

R5 > R1 > R12 >|> R22

1. R5, R1 and R12 are OSPF configured with R5,R1 in area 1 and R1,R12 in area 0

2. R5 and R12 are iBGP peers

3. R12 and R22 are eBGP peers

 I am trying to ping from R5 to R22 and wasn't able to until I configures a static route on R1 with R2 as the gateway. Without the static route R1 was dropping packets meant for R22 as that destination was not in R1s routing table. R5 however knew R22 though BGP.

My question is, would redistributing OSPF into BGP and vice versa on R12 could have solved this? Redistributing BGP in OSPF sounds dangerous.

If there were 2 more routers between R1 and R12, would each router should have a static route configured? I was trying to base all my routing on IGP routing without any static routes. Is that possible for eBGP connectivity.

Appreciate any insight. Thanks.

[paul driver]

Hello

As R5 is an ibgp peer to r12 which has an ebgp face peering to R22.
So when the ebgp routes at advertised to R5, by default they would be advertised with R12-R22 transit subnet next hop address and as as such R5 would not be aware of this.

To fix this - on R12 ibgp peering towards R5
router bgp xx
neighbor <R5ip> next hop-self

Redistributing BGP in OSPF sounds dangerous.

Mutual redistribution between igp and bgp can be dangerous is you have multiple redistribution points as it possible to incur loops if you dont safe guard against reintroduction of learned prefixes.

Also depending if you are receiving full internet route table it could overwelm the routers memory process if you haven't enough memory to accommodate it.

 I was trying to base all my routing on IGP routing without any static routes. Is that possible for eBGP connectivity.

As long has bgp has NLRI between it peers then you should be okay, and to do this its suggested you do in fact use an IGP for the underlying connectivity so it is possible to do this.

res
Paul

[NInja Black]

Thanks for the response Paul.

I did actually configure the next-hop-self on R12 initially but it did not work. still to confirm I removed the default route in R1 and reconfigured the NHS command on R12 and lost connectivity. Running a debug on R1 shows R1 is dropping packets. Please advise what I might be missing. Below is the relavant config of the routers.

R5:

R5#sh run | s bgp
router bgp 64512
 bgp log-neighbor-changes
 neighbor 12.12.12.2 remote-as 64512
R5#

R5#sh run | s ospf
 ip ospf hello-interval 1
 ip ospf 1 area 1
router ospf 1
 router-id 5.5.5.5
 redistribute connected
R5#

R1

R1#sh run | s ospf
 ip ospf hello-interval 1
 ip ospf 1 area 0
 ip ospf hello-interval 1
 ip ospf 1 area 1
router ospf 1
 router-id 1.1.1.1
 redistribute connected
R1#

R12:

R12#sh run | s bgp
router bgp 64512
 bgp log-neighbor-changes
 network 15.15.15.0 mask 255.255.255.0
 network 22.22.22.0 mask 255.255.255.0 
 neighbor 15.15.15.5 remote-as 64512
 neighbor 15.15.15.5 next-hop-self
 neighbor 22.22.22.20 remote-as 64523
R12#

R12#sh run | s ospf
 ip ospf hello-interval 1
 ip ospf 1 area 0
router ospf 1
 redistribute connected
R12#

R22:

R22#sh run | s bgp
router bgp 64523
 bgp log-neighbor-changes
 network 22.22.22.0 mask 255.255.255.0
 network 55.55.55.0 mask 255.255.255.0
 neighbor 22.22.22.2 remote-as 64512
 neighbor 55.55.55.30 remote-as 64523
R22#

[paul driver · Accepted solution]

Hello

make area 1 as a total stub area And remove the redistributed connect and just advertise via ospf network command

Also make rtrs 5/1/12 ibgp peers (full mesh) with rtr12 with next hop self towards both its ibgp peering 

Remove all statics

Test again.

res

paul

[Masoud Pourshabanian]

Hello,

As Paul suggested, R5, R1 and R12 should be IBGP peers(full mesh) 

[edited, typing mistake]

or R5<>R1 and R1<>R12, then R1 must be a route-reflector.

Best,

Masoud

[paul driver]

Hello

R1<>R5 and R5<>R12, then R5 must be a route-reflector.

Not required.....Given the amount of peers

res
Paul

[Masoud Pourshabanian]

Not required.....Given the amount of peers

In the example, using default routes is a better solution since there is no redundant links; however, we are talking about the concept.

By default, IBGP does not advertise routes received from IBGP peers to avoid routing loop. The solution for that:

1- Full mesh among peers

2- Using route-reflector/confederation

Even in this example, route-reflector is a better solution than full mesh

If full mesh,

1- R5 will establish two IBGP sessions (to R1 and R12)

2-R5 will receives two redundant updates from R1 and R12. It means using more memory. Suppose R12 receives a full BGP table, then R5 will have 2 * full BGP routes.

If route-reflector is used, R5 will establish only one IBGP session and  receive one copy of updates. The only drawback is delay caused by route-reflector which is negligible if network is stable.

Best,

Masoud

[paul driver]

Hello Massoud

RR /Confederations is mainly to address scalability surrounding large full mesh ibgp peerings( to decease the ibgp  peerings)

As there is only 3 ibgp peerings and one of them is an ebgp /ibgp facing rtr (R12) in this topology Then I would say in my humble opinion initiating RR inst a valid option.

Rtr12 is the only possible real candidate as a RR and If either of the other ibgp peers lost their connection to R12 then they would become isolated.

If you have one of the ibgp rtrs also as a RR then you still have 3 ibgp peerings, which then negates having RR in the first place


res
Paul

[NInja Black]

I was trying a partial mesh setup. Using a static route seemed to me as the simplest solution but again I wanted to see if I the IGP would take of the routing. Evidently it doesn't for eBGP connectivity.

Will test our with all the proposed options this week. 

Sincerely appreciate all the responses. Gives me a better understanding of BGP.

Thanks. :)