OSPF + BGP routing assistance

[vaultnetworks]

Hey All,

I'm trying to setup some new gear and am looking for a way to connect my border routers together through so they can see each other eBGP routes through iBGP. The bgp configuration portion is very straight forward and each of the border routers is able to obtain the routes correctly. However the problem lies in sending traffic to the next hop stated in the BGP table.

My network is setup with BGP and OSPF with 4x 6500's running the latest SXJ code. I cannot connect the 2 borders together because they reside in different buildings and having the circuits connected at the core level gives another layer of redundancy in the event one Broder router failure. All packets make it to the CORE but then it seems like OSPF takes over and routes them whichever way it wants to. What additional configurations need to be put in place to ensure packets get delivered to the other side that are suppose to?

BorderRTR1 ---- CORE1 ------ CORE3--- BorderRTR4.

[lamav]

Brian, you're barely coherent. Post a diagram and post the configs of all the devices, and then explain what doesnt work.

[milan.kulik]

Hi,

if I understand correctly, you are running an iBGP session through the core layer routers running OSPF only?

And with "no synchronization" in the BGP config  probably?

If yes, so the BGP routers are advertising the BGP prefixes each to the other.

But when a packet is routed using this BGP route, the sending BGP routers has to find the next-hop recursively.

(As the next-hop in the BGP table is the other BGP router which is not reachable directly.)

As a result, the packet is sent to the core router.

And the core router is routing it based on his routing table - don't forget IP routing is always per-hop behaviour!

So if you are not synchronising BGP and OSPF routing tables, the core router could even drop the packet or forward it according to his default route, depending on his routing table.

I'm not sure what your goal is.

You might need to configure a tunnel through the OSPF cloud possibly, if you don't want to overload the OSPF database with all the BGP prefixes?

HTH,

Milan

[vaultnetworks]

Milan,

Yes that's correct. I'm running it through the core layer which is only running OSPF. and BGP does have the "no synchronization" directive.

Presently we are running iBGP through L2 trunk from BorderRTR1 through the core to BorderRTR4 and it works fine. Last go around with this, we tried to load the BGP prefixes into OSPF on an old Sup2 MSFC2 engine several years ago and there were simply to many routes for that engine to handle. Now we're upgrading to Sup720-3B engines on the core and 3BXL's on the Border and wanted to give this another go around. I know there's gotta be a cleaner way to do ibgp over the network with L3 devices inbetween that only have local OSPF routes but my experience is limited in this area. I haven't tried to load the bgp table into OSPF on the 720-2b's yet and I know they don't have enough memory to support full routing tables. Do you recommend I try that or just go with an ip tunnel? If so, can  you point me to some documentation or examples of howto create the tunnel?

[milan.kulik]

Hi,

I'm missing your point probably.

If you are able to run an L2 connection (a separate VLAN?) between your BGP routers, why do you want to change anything?

Especially when your core L3 switches are not capable to handle the full BGP table?

You could try to build GRE tunnels, e.g., but then you have to fight with MTU troubles, etc.

(see http://www.cisco.com/en/US/customer/tech/tk827/tk369/technologies_tech_note09186a0080093f1f.shtml ).

BR,

Milan

[vaultnetworks]

Milan,

Thanks for your help! We use to have only L3 at the border and hundreds of vlans spanning  across the core and access layers with trunks, port channels, STP...... It was a mission to manage and deploy  new customers onand clean up those who left. Since we've gone to an all L3 network, life has been so much simplier. There are only a hand full of Vlans/STP on the network for situation where customers want multiple ports or while a miantenance window is open and ibgp over multi hop did not work correctly. When something breaks, it's easier for us to troubleshoot a L3 issue remotely than to find out which link along the trunk line is acting up or where STP got hung up at. Not that either are hard to troubleshoot, just a matter of personal preference for our situation and experience.

That being said, I do have another Border router connected to BorderRTR4 which we'll call BorderRTR3. I was able to set the direct L3 link between them with mtu 9216, which didn't seem to effect the connection but we're doing that for all of our links to ensure there are no issues with future mpls tunnels etc.. With your help and a couple examples on-line, I was able to get a session up and running using a tunnel. Now to see if it can be done through the core.

BorderRTR4---------
interface Tunnel0
ip address 10.1.2.1 255.255.255.252
tunnel source Loopback0
tunnel destination 206.253.168.186
!
router bgp 32632
neighbor 10.1.2.2 remote-as 32632
neighbor 10.1.2.2 update-source Tunnel0
neighbor 10.1.2.2 next-hop-self
neighbor 10.1.2.2 soft-reconfiguration inbound
!
ip route 10.1.2.0 255.255.255.252 Tunnel0

BorderRTR3---------

interface Tunnel0
ip address 10.1.2.2 255.255.255.252
tunnel source Loopback0
tunnel destination 206.253.168.185
!
router bgp 32632
neighbor 10.1.2.1 remote-as 32632
neighbor 10.1.2.1  update-source Tunnel0

neighbor 10.1.2.1 next-hop-self
neighbor 10.1.2.1  soft-reconfiguration inbound

!
ip route 10.1.2.0 255.255.255.252 Tunnel0