RE: Cluster id - ASBR ID Match stipulation when synchronisation

It's a legacy rule per RFC 1403, "BGP OSPF Interaction" Section 3:

<RFC 1403>
3. BGP Identifier and OSPF router ID

   The BGP identifier MUST be the same as the OSPF router id at all
   times that the router is up.

   This characteristic is required for two reasons.

     i Synchronisation between OSPF and BGP

          Consider the scenario in which 3 ASBRs, RT1, RT2, and RT3,
          belong to the same autonomous system.

<snip>

          Both RT1 and RT2 have routes to an external network X and
          import it into the OSPF routing domain. RT3 is advertising
          the route to network X to other external BGP speakers. RT3
          must use the OSPF router ID to determine whether it is using
          RT1 or RT2 to forward packets to network X and hence build the
          correct AS_PATH to advertise to other external speakers.

          More precisely, RT3 must determine which ASBR it is using to
          reach network X by matching the OSPF router ID for its route
          to network X with the BGP Identifier of one of the ASBRs, and
          use the corresponding route for further advertisement to
          external BGP peers.

     ii It will be convenient for the network administrator looking at
          an ASBR to correlate different BGP and OSPF routes based on
          the identifier.
</RFC 1403>

Cisco implements this as part of the BGP Bestpath Selection criteria:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml

"If BGP synchronization is enabled, there must be a match for the prefix in the IP routing table in order for an internal BGP (iBGP) path to be considered a valid path. BGP synchronization is enabled by default in Cisco IOS. Software. If the matching route is learned from an Open Shortest Path First (OSPF) neighbor, its OSPF router ID must match the BGP router ID of the iBGP neighbor. Most users prefer to disable synchronization with use of the no synchronization BGP subcommand."

The simple fix for this is to disable synchronization under BGP (which in current versions it's already disabled), and then either run iBGP everywhere, or just run iBGP on the edge and MPLS in the core.

The synchronization rule basically was used to prevent a blackhole case where you were transiting non-BGP speaking routers, or a route deflection problem where the path selection of iBGP and IGP is not synchronized and either a traffic loop or suboptimal routing could occur.

So in other words, yes, the behavior you're seeing is normal.

HTH,

Brian McGahan, 4 x CCIE #8593 (R&S/SP/SC/DC), CCDE #2013::13
bmcgahan_at_INE.com
 
Internetwork Expert, Inc.
http://www.INE.com

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Imran Ali
Sent: Monday, September 23, 2013 12:03 PM
To: Cisco certification
Subject: Cluster id - ASBR ID Match stipulation when synchronisation is enabled

Hi all

it is mentioned that when we have BGP synchronisation rule enabled , ASBR
must be the must also be route reflector. why is this so

to test out ...

R2----R1----R3

R1 is hub and R2 , R3 are spokes
172.16.101.1 , 172.16.102.1 , 172.16.103.1 are router id of R1,R2, and
R3.

*R2 as ASBR and RR*

router bgp 100
* synchronization*
 bgp log-neighbor-changes
 network 20.20.20.0 mask 255.255.255.0 ----> Advertises this network
 neighbor 172.16.20.10 remote-as 200
 neighbor 172.16.123.1 remote-as 100 ----> R1 as ibgp RR client
 neighbor 172.16.123.1 route-reflector-client
 neighbor 172.16.123.3 remote-as 100
 neighbor 172.16.123.3 route-reflector-client ---->R3 as ibgp RR
client

router ospf 1
 log-adjacency-changes
 redistribute bgp 100 subnets ----> obeying what synchronisation rule
says

*on R3*

R3#show ip bgp 20.20.20.0
BGP routing table entry for 20.20.20.0/24, version 3
Paths: (1 available, best #1, table Default-IP-Routing-Table,
RIB-failure(17))
  Advertised to update-groups:
     2
  Local
    172.16.123.2 from 172.16.123.2 (172.16.102.2)
      Origin IGP, metric 0, localpref 100, valid, internal, *synchronized,
best*

on R1 (ASBR ONLY , NOT RR)
R1#show ip bgp 20.20.20.0
BGP routing table entry for 20.20.20.0/24, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table,
RIB-failure(17))
  Advertised to update-groups:
     1
  Local
    172.16.123.2 from 172.16.123.2 (172.16.102.2)
      Origin IGP, metric 0, localpref 100, valid, internal, *synchronized,
best*

all ok here

now if i advertise on R1 network 10.10.10.0

router bgp 100
 synchronization
 bgp log-neighbor-changes
 network 10.10.10.0 mask 255.255.255.0

R3 receives it but says this

R3#show ip bgp 10.10.10.0
BGP routing table entry for 10.10.10.0/24, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Local
    172.16.123.1 from 172.16.123.2 (172.16.102.2)
      Origin IGP, metric 0, localpref 100, valid, internal*, not
synchronized*
      Originator: 172.16.101.1, Cluster list: 172.16.102.2

if i look for a matching route in IGP
*
R3#SHOW IP ROUTE 10.10.10.0*
Routing entry for 10.10.10.0/24
  Known via "ospf 1", distance 110, metric 1, type extern 2, forward metric
64
  Last update from 172.16.123.1 on Serial1/0, 00:09:43 ago
  Routing Descriptor Blocks:
  * 172.16.123.1, from 172.16.101.1, 00:09:43 ago, via Serial1/0
      Route metric is 1, traffic share count is 1

Indeed the route is present ...

why does cluster id needs to be same as ASBR advertising ip when
synchronisation is enabled ????

is this as per RFC or just cisco implementation ???

i did debug ip bgp update ...to see actual message

i am advertising a new network now 100.100.100.0

*Mar 1 04:03:09.906: BGP(0): 172.16.123.2 rcvd UPDATE w/ attr: nexthop
172.16.123.1, origin i, localpref 100, metric 0,* originator 172.16.101.1,
clusterlist 172.16.102.2*
*Mar 1 04:03:09.914: BGP(0): 172.16.123.2 rcvd 100.100.100.0/24
*Mar 1 04:03:09.918: BGP(0): no valid path for 100.100.100.0/24
R3#
*Mar 1 04:03:23.842: BGP(0): *no valid path for 100.100.100.0/24*
R3#sr 100.100.100.0
Routing entry for 100.100.100.0/24
  Known via "ospf 1", distance 110, metric 1, type extern 2, forward metric
64
  Last update from 172.16.123.1 on Serial1/0, 00:00:51 ago
  Routing Descriptor Blocks:
  * 172.16.123.1, from 172.16.101.1, 00:00:51 ago, via Serial1/0
      Route metric is 1, traffic share count is 1

and when advertise on R2 (RR AND ASBR)

*Mar 1 04:09:51.070: BGP(0): 172.16.123.2 rcvd UPDATE w/ attr: nexthop
172.16.123.2, origin i, localpref 100, metric 0
*Mar 1 04:09:51.074: BGP(0): 172.16.123.2 rcvd 200.200.200.0/24
*Mar 1 04:09:51.078: BGP(0): *Revise route installing 1 of 1 routes for
200.200.200.0/24 -> 172.16.123.2(main) to main IP table*
*Mar 1 04:09:51.086: BGP(0): 172.16.35.5 send UPDATE (format)
200.200.200.0/24, next 172.16.35.3, metric 0, path Local
*Mar 1 04:09:51.190: BGP(0): Revise route installing 1 of 1 routes for
200.200.200.0/24 -> 172.16.123.2(main) to main IP table

*R3#SHOW IP BGP 200.200.200.0*
BGP routing table entry for 200.200.200.0/24, version 5
Paths: (1 available, best #1, table Default-IP-Routing-Table,
RIB-failure(17))
Flag: 0x820
  Advertised to update-groups:
     2
  Local
    172.16.123.2 from 172.16.123.2 (172.16.102.2)
      Origin IGP, metric 0, localpref 100, valid, internal, s*ynchronized,
best*

Blogs and organic groups at http://www.ccie.net
Received on Mon Sep 23 2013 - 14:32:13 ART