Topolog Question: Administrative distance OSPF / IBGP

[Gomez]

Hello,

I have the following topology.  A backbone Area 0 and 2 different area's for WAN connections comming from ISP 1 and ISP2.

The Fortinet is protecting traffic coming in and out to the remote sites (areas).  Area 202 has Fortinet in (ABR) and 2 ASBR primary/backup router.  The ASBR is using OSPF (to internal) and MP-BGP (IBGP) to route reflector RR(BEL PE1).

Config of the 2 ASBRS is the following:

PRIMARY ASBR

router ospf 2 vrf VRF1
capability vrf-lite
redistribute bgp 65000 subnets route-map TAG666
passive-interface default
no passive-interface GigabitEthernet0/0.2002
distance 205
router ospf 1
passive-interface default
no passive-interface GigabitEthernet0/1
router bgp 65000
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source Loopback0
!
address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community extended
exit-address-family
!
address-family ipv4 vrf VRF1
redistribute ospf 2 metric 10 match internal external 1 external 2 route-map T AGG555
exit-address-family

SECONDARY ASBR

router ospf 2 vrf VRF1
capability vrf-lite
redistribute bgp 65000 subnets route-map TAG555
passive-interface default
no passive-interface GigabitEthernet0/0.2003
distance 205
router ospf 1
passive-interface default
no passive-interface GigabitEthernet0/1
router bgp 65000
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source Loopback0
!
address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community extended
exit-address-family
!
address-family ipv4 vrf VRF1
redistribute ospf 2 metric 120 match internal external 1 external 2 route-map TAG666
exit-address-family

the route tags ar just tagging routes no prefixes or anything just for loop prevention tagging al routes.

The issue I had was that when I shutdown the primary device and failover to the secondary and then re-enable again the primary the routing table was preferring OSPF path 10.30.0.0/16 over the IBGP route so I modified the administrative distance of the OSPF process to solve this.  (return traffic was taking another path so the Fortinet dropped it as asymmetric routing)

Is there a more elegant solution then adjusting the administrative distance for this?

[Giuseppe Larosa]

Hello @Gomez ,

can you post the configuration of the route-maps used to control mutual redistribution ?

Because looking at the names we see:

ASBR1:

>>

router ospf 2 vrf VRF1
capability vrf-lite
redistribute bgp 65000 subnets route-map TAG666

address-family ipv4 vrf VRF1
redistribute ospf 2 metric 10 match internal external 1 external 2 route-map T AGG555
exit-address-family

ASBR2:

>>

router ospf 2 vrf VRF1
capability vrf-lite
redistribute bgp 65000 subnets route-map TAG555

address-family ipv4 vrf VRF1
redistribute ospf 2 metric 120 match internal external 1 external 2 route-map TAG666
exit-address-family

Comparing the two routers I see that the names of the route-maps are swapped TAG666 is used on ASBR 1 for BGP to OSPF 2 redistribution and on ASBR2 it is used for redistribution of OSPF 2 into MP BGP AF vrf VRF1, and the opposite happens for route-map TAG555.

If the route-maps names mean same configuration on both routers I would say this is wrong both routers should use the same tagging rules for loop avoidance.

Hope to help

Giuseppe

[Gomez]

Hi Giuseppe,

BEL-BE-SECONDARY#

show route-map
route-map TAG666, deny, sequence 10
Match clauses:
tag 666
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map TAG666, permit, sequence 20
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map TAG555, permit, sequence 10
Match clauses:
Set clauses:
tag 555
Policy routing matches: 0 packets, 0 bytes
route-map TAG555, permit, sequence 20
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes

BEL-PE-PRIMARY>show route-map
route-map TAGG555, deny, sequence 10
Match clauses:
tag 555
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map TAGG555, permit, sequence 20
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map TAG666, permit, sequence 10
Match clauses:
Set clauses:
tag 666
Policy routing matches: 0 packets, 0 bytes
route-map TAG666, permit, sequence 20
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes

[Giuseppe Larosa]

Hello @Gomez ,

thanks for providing the route-maps configuration on both ASBR1 and ASBR2.

I have the following notes:

a) the route-map names are a little misteading as their configuration is different on the two routers

b) You are actually only controlling that routes coming from BGP are not injected again into BGP.

c) To implement an effective and equivalent check on BGP for routes that are originally generated in OSPF and then injected in BGP you can use a BGP community value like 65000:51

in the case of ASBR1

ip community-list 51 permit 65000:51

route-map TAG666 deny 5

match community 51

route-map TAG666 permit 10

set tag 666

set community 65000:51

You need send-community both under AF vpnv4 to able to send and receive standard BGP communities.

The same can be done on ASBR2 for route-map TAG555

Hope to help

Giuseppe

[MHM Cisco World]

config the iBGP between the two edge routers/FW if you redistribute the prefix from ibgp to OSPF in each edge router/FW. 
this make edge router/FW even if it learn prefix from other edge router it will prefer the direct connect iBGP peer "after you reduce the OPSF AD".

[Gomez]

Hi,

Thank you for you reply.  I will give it a try and let you know.  

[MHM Cisco World]

You are welcome ,

just mention again not use ospf between the two edge router/fw they direct connect so only config ibgp between them.

[paul driver]

Hello

Try increasing the default bgp weight on both rtrs to be higher than 32768 and test again 

[Gomez]

Tnx Paul.

"https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/213285-understand-the-importance-of-bgp-weight.html"

I have tried you solution after also reading the above article.  It doesn't seem to work since I am using IBGP on the PE routers and OSPF to the FORTINET.  The administrative distance will be checked first.

So on the ASBR OSPF is always used as routing protocol.

[paul driver]

Hello
That wasn’t the reason why i suggested using weight, The reason was incase you were experiencing a race condition between ospf and bgp as such that original ebgp prefixes were being redistributed into ospf and than back into bgp of which, when a redistributed prefix enters bgp rib it has a default weight of 32768 assigned to it thus given the bgp path selection process weight would take precedence of an original ebgp route from the isp which isn’t assigned any weight