Why that subnet is included in OSPF configuration?

[turbo_engine26]

Hi,

Please find attached scenario and configuration screenshot.

As you see, a link is added between Vail and Telluride in case if one of Aspen links fail to prevent AS 400 to become isolated. This link runs IBGP between both routers. Because this is an iBGP link, both routers will exchange BGP routes freely and automatically enters those routes into the routing table. Anyways, this link is advertised to OSPF through the BGP-to-OSPF redistribution. However, the book included that link in the OSPF configuration because as the book says "Without it, the iBGP session will not form" ... I did't get this part because the link is physical not logical between Vail and Telluride. Before the link was logical and the TCP session was performed through Aspen that's why we needed Aspen to know about this link. But now, it is physical so the iBGP (TCP) session should be formed without including that link in the OSPF config.

Thx

Regards,

A.M.

[Edison Ortiz · Accepted solution]

You are correct - for this case - you don't need to have the physical links under OSPF as the iBGP peering relationship is done with the physical interfaces vs the loopback.

[turbo_engine26]

Thx for your reply.

I found something interesting. Actually, the book used the link under OSPF configuration not because iBGP peering will not be established but because synchronization is turned on so we need to include this link under OSPF in ordered to be entered in the IGP table. For example, if i remove the link under OSPF network config, Telluride won't reach the AS 200 networks through Vail but it will reach them through Aspen even though there is an internal BGP peering with Vail. The BGP peering will not has a benefit if sync. is on because AS 200 networks won't be in the IGP table. On the other hand, if i turned sync. off, Vail now can advertises AS 200 networks through BGP and Telluride enters them in the routing table. In short, because sync. is turned on, we must include the link between Vail and Telluride under OSPF in order for Telluride to reach AS 200 through Vail and Vail to reach AS 400 through Telluride since we are running IGP inside. That was a misleading sentence from the book when it said "The iBGP won't form if that link is not included under OSPF".

HTH

A.M.

[Edison Ortiz]

Yes, trick questions that make you think. BTW, with newer IOS versions synchronization is turned off by default and it won't actually show in the running-config so the book may need some updating to reflect the new behavior

[turbo_engine26]

Well, the book was released in 2001 . however, Cisco recommends this book because the BGP concept itself is not changed. These minor changes in IOS can be recognized easily through working experience or through Cisco webpages. BTW, the disabled sync. is shown in the running-config with "no sync." statement in 12.4.

HTH

A.M.

[turbo_engine26]

Sorry, i was mistaken when i said "On the other hand, if i turned sync. off, Vail now can advertises AS 200  networks through BGP and Telluride enters them in the routing table". Actually, Telluride will still prefer Aspen if i turn off sync. because OSPF AD is lower than iBGP AD. However, after i shutdown one of Aspen's links, iBGP now is shown in the routing table.

Sounds like i am posting a question and answer myself. But, i need someone to correct me if i am wrong.

HTH

A.M.

[Jon Marshall · Accepted solution]

You are correct. Vail redistributes BGP routes from AS 200 into OSPF. Vail also advertises routes from AS 200 via IBGP to Telluride. So Telluride has 2 sets of routes to pick from and it chooses OSPF routes because of the lower AD.

If you don't run OSPF on the Vail -> Telluride direct link and then shutdown one of the links between Vail -> Aspen -> Tellruide then. as you say, Telluride stops receiving the OSPF routes and so only has the IBGP routes to use for AS 200.

Jon

[turbo_engine26]

Exactly! i concluded the following from this scenario:

1- If one of Aspen's links fail, the additional link between Vail and Telluride should run OSPF in order to carry the resdistributed BGP AS 200 routes from Vail.

2- If one of Aspen's links fail and no OSPF configured between Vail and Telluride, sync. should be disabled in order to carry the native BGP AS 200 routes from Vail. (Not recommended solution because of a manual config. intervention)

3- If one of Aspen's links fail, no OSPF configured and Sync is not disabled, no routes will exist in Telluride at all for AS 200

I am so happy now that i fully understand BGP from all angles, Thanks God first then Thanks to all who contributed in providing the best answers. Synchronization now is very clear to me if i run an IGP in the AS. RR and Confederations are very easy to understand as well. I can say that BGP is very simple protocol, even simpler than OSPF. The trick in BGP is not the implementation of the protocol itself but the trick is using the proper filtering tools to block or allow specific routes from/to an AS.

Thanks Jon and Edison.

HTH

A.M.

[Edison Ortiz]

turbo_engine26 wrote:
I am so happy now that i fully understand BGP from all angles, ..... I can say that BGP is very simple protocol, even simpler than OSPF. The trick in BGP is not the implementation of the protocol itself but the trick is using the proper filtering tools to block or allow specific routes from/to an AS. 
Thanks Jon and Edison.
HTH
A.M.

You have no idea how complicated BGP can be if you said that but I'm glad understand the issue at hand.

Please remember to rate helpful posts.

Regards,

Edison

[turbo_engine26]

As i said, the complication comes when using filtering tools such as route maps, distribute lists, AS_Path filter lists, prefix lists and so on. However, the standard BGP configuration is very simple even if we use peer groups and communities. The confusion comes when you plan which routes enters and which routes goes out based on MED, Local_Pref, Weight ... etc. The problem also with BGP is you have to deal with your ISP's team about handling those configurations without arguments and headache. However, sometimes you face problems with their staff such as personal arguments, human errors in their side, bad attitude ...etc . In this case, BGP is a headache and complex. otherwise it is lovely.

HTH

A.M.