Task 2.4 - BGP Router ID

Hi, I wonder if somebody can help as something has got me confused.  In the SG for this particular task it states that you need to amend the BGP router ID of R4 to 150.1.5.5.  This being due to the fact that with synchronisation that when redistributing from BGP into OSPF you need to ensure that the OSPF ASBR router ID matches the originating BGP Router ID.  I just don;t understand this as R4 does not run OSPF and R5 does not run BGP.

Can somebody please explain this to me.

Thanks, Ian

Comments

  • A very interesting task... I'm also left with he same question...

    Tech Edit/Christian : Is this an oversight or am I missing something here?

    Thanks,

    Eric

  • Again looking at this task, I'm not sure why routes are tagged on R6 during bgp to ospf redistribution and then again redistributed from ospf to rip matching on this tag on R5 since we already send a default route to the routing domain. If R4 and R6 received a different set of routes from AS54, this kind of solution may come in handy but in this case, simply sending the bgp routes into ospf would be "good enough" as far as I can understand. Sounds like a clear case of overthinking...

    Eric

  • Hi Ian & Eric,

      If BGP synchronization is enabled, you need a match for the BGP prefix in the routing table in order for the path to be valid. The match in the routing table can be via any IGP or static; when the protocol is OSPF the OSPF RID of the prefix must match the BGP RID of the iBGP neighbor. As R5, with RID 150.1.5.5, is the one redistributing BGP prefixes into OSPF (known via RIP from R4) it means that R4 needs to have a BGP RID of 150.1.5.5. If you do not set this on R4, you'll see that on R6 prefixes are not synchronized in the BGP table.

    Hope is makes sense,

  • Hi Eric,

       This is because, again, of the BGP synchronization process. R4 needs specific prefixes in its routing table to match the BGP learned prefixes; otherwise it will not be synchronized; synchronization process does not match on the default route.

    Hope it makes sense,

    Again looking at this task, I'm not sure why routes are tagged on R6 during bgp to ospf redistribution and then again redistributed from ospf to rip matching on this tag on R5 since we already send a default route to the routing domain. If R4 and R6 received a different set of routes from AS54, this kind of solution may come in handy but in this case, simply sending the bgp routes into ospf would be "good enough" as far as I can understand. Sounds like a clear case of overthinking...

    Eric

     

  • Hi,

    Are the route-maps for redistributing BGP into the IGPs (RIP and OSPF) really required? I think those are not required since we are alredy filtering the routes we receive from the BBs (odd in R4 and even in R6) and the default behavior when redistributing BGP into IGP is to just redistribute eBGP routes unles "bgp redistribute-internal" is configured, so odd routes won't be reditributed by R6 into OSPF, since those will be learned via iBGP from R4, and the other way around will happen with even routes. Is my understanding correct? Or did I miss anything along the path?

    Thanks,

    Jorge

  • Hi Jorge,

    I'm going over this redisitrbution scenario for the second time (definitely one of my favs in vol2). From your comment, it seems you filtered out proper odd/even routes on R4 and R6 from BB3 and BB1 respectively. I used the same methodology and it seems to work fine for me.
    Redistributing even routes from ospf to rip on R5 was not needed (thanks
    to the default route) and every prefix is reachable from all internal
    hosts. The SG presents an alternate solution in which they allow ALL odd and even routes on R4 and R6 and only redistribute the proper ones in the IGP.

    I find that synchronization is what's most interesting here. In this case, un-synchronized routes don't break reachability since we are saved by our IGPs (even when synchronized on R6, odd routes have rib-failures since it prefers to use it's OSPF routes and R4 always has a default route through R5 anyways). But it shows the tricks that need to be used to make synchonisation "happen".

    For INE: if there was a requirement to have all odd and even routes synchronized on R4 and R6, it would kinda force the student to do the task in the way that is presented in the SG.

    Regards,

    Eric

  • I agree with Eric.

     

    This scenario is definitely awesome.

     

    The BGP router ID that need to match the OSPF ID is tricky. I put that note into my short notes book but I forgot about this one ...

     

    Will do that lab next month for sure ;)

     

     

     

    Thanks for the post guys, helped in my study

  • Hi Guys!

    I hope this summarisation makes since to everybody:

    since BGP synchronization is enabled, as we all know,  then we need an exact match in the IGP routing table for the learned iBGP prefixes to be considered in the BGP best path selection

    The interpretation for the above rule from R4 and R6 prespective is as follows:

    1- for R4 to install R6's iBGP prefixes it needs an exact IGP prefix match in it's routing table.

    Since R5 is advertising a default router to the RIP domain this is not enough to satisfy the synchronisation rule, so we specifically redistribute those "IGP learned - iBGP prefixes from R6" at R5 to RIP by matching the tag inserted by R6.

     

    2- for R6 to install R4's iBGP prefixes it needs an exact IGP route in it's routing table. - which is satisfied, but in addtion to that since R6's IGP is OSPF one additional rule must be met:

    the ASBR OSPF RID must match the BGP RID and this is fixed by changine R4's BGP RID to be same as R5's ASBR OSPF RID.

     

    NOTE- if the whole IGP domain was OSPF then there is no need for this step!!

    i personally thing there is no need for the route-map in the RIP-to-BGP redistribution at R4 and OSPF-to-BGP redistribution at R6.

    Also, back to the second point in the task, i think the shorter answer on R4 to advertise VLAN5 specifically is to configure it asfollows:

    router bgp 100

    network 139.1.5.0 mask 255.255.255.0

    aggregate-address 139.1.0.0 255.255.0.0

    !

    This advertised the aggregate as well as VLAN5 only.

    it worked fine for me, short and sweet :) I like short answers as they are what you need in the real lab to save time! :):P

    Awsome task!

     

  • If You want a "little" increase a difficulty of this lab, try to achieve the same goals but without filtering on eBGP sessions.

  • I still don't get it.  For one I can ping all bgp prefixes throughout.  Also when I traceroute from all routers the routes are directed where they should and this is before i change the router-id.

     

    Why is the router id that of R5?  R6 is the ASBR for OSPF.  R4 is redistributing into RIP not OSPF.  R5 is redistributing rip into OSPF not bgp into OSPF.  The router-id's for BGP and OSPF already match on the R6 ASBR so it's not a problem there.  I'm definitely missing something.


  •  54 50 60

        150.1.4.4 (metric 1583) from 150.1.4.4 (150.1.5.5)

          Origin IGP, metric 0, localpref 100, valid, internal, not synchronized

      54 50 60

        54.1.2.254 from 54.1.2.254 (212.18.3.1)

          Origin IGP, metric 0, localpref 100, valid, external, best

    I get the above no matter what bgp router id I set R4 to.  My traceroutes and pings all work from the intern IGP domain exactly as they should also with or without as I'm only redistributing the evens on one side and odds on the other so I really don't see what the router-id is doing here.

  • I can get this to fail and work based on having the BGP router-id set if I change the BGP distance to 200 so that the BGP route doesn't take precedence over the Igp routes.  When I do this on R6 for example sh ip bgp 113.0.0.0 shows syncronized with a router-id of 150.1.5.5 but not if I remove it.  However w/out this it shows not syncronized either way and I'm guessing because the EBGP route is in the routing table so it therefore is not sync'd with an igp.

  • Fully agree with you on the aggregate without summary-only....there was no requirement that only the aggregate had to be sent!

     

    Also, Ive used MED as appose to just importing the specific BGP routes as per the SG.....

     

    see extract below!

    R6


    router bgp 100

     synchronization

     bgp router-id 150.7.6.6

     bgp log-neighbor-changes

     network 139.7.6.0 mask 255.255.255.0 route-map FILTER

     aggregate-address 139.7.0.0 255.255.0.0

     neighbor 54.7.2.254 remote-as 54

     neighbor 150.7.4.4 remote-as 100

     neighbor 150.7.4.4 update-source Loopback0

     neighbor 150.7.4.4 next-hop-self

     no auto-summary

    alias exec cr sh run  |  s router

    Rack7R6#sh run  | s route-map

     network 139.7.6.0 mask 255.255.255.0 route-map FILTER

    route-map FILTER permit 10

     set community no-advertise


    router ospf 1

     router-id 150.7.6.6

     log-adjacency-changes

     redistribute bgp 100 subnets




    Rack7R6#br

    BGP table version is 20, local router ID is 150.7.6.6

    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

                  r RIB-failure, S Stale

    Origin codes: i - IGP, e - EGP, ? - incomplete


       Network          Next Hop            Metric LocPrf Weight Path

    *> 28.119.16.0/24   54.7.2.254                             0 54 i

    * i                 150.7.4.4                0     50      0 54 i

    *> 28.119.17.0/24   54.7.2.254                             0 54 i

    * i                 150.7.4.4                0     50      0 54 i

    *> 112.0.0.0        54.7.2.254               0             0 54 50 60 i

    * i                 150.7.4.4                0     50      0 54 50 60 i

    r  113.0.0.0        54.7.2.254               0             0 54 50 60 i

    r>i                 150.7.4.4                0    200      0 54 50 60 i

    *> 114.0.0.0        54.7.2.254               0             0 54 i

    * i                 150.7.4.4                0     50      0 54 i

    r  115.0.0.0        54.7.2.254               0             0 54 i

    r>i                 150.7.4.4                0    200      0 54 i

    *> 116.0.0.0        54.7.2.254               0             0 54 i

    * i                 150.7.4.4                0     50      0 54 i

    r  117.0.0.0        54.7.2.254               0             0 54 i

    r>i                 150.7.4.4                0    200      0 54 i

    *> 118.0.0.0        54.7.2.254               0             0 54 i

       Network          Next Hop            Metric LocPrf Weight Path

    * i                 150.7.4.4                0     50      0 54 i

    r  119.0.0.0        54.7.2.254               0             0 54 i

    r>i                 150.7.4.4                0    200      0 54 i

    *> 139.7.0.0        0.0.0.0                            32768 i

    * i                 150.7.4.4                0    100      0 i

    r>i139.7.5.0/24     150.7.4.4                2    100      0 i

    *> 139.7.6.0/24     0.0.0.0                  0         32768 i

    Rack7R6#







    R5



    router rip

     version 2

     timers basic 3 18 18 24

     redistribute ospf 1 metric 5


    R4



    router rip

     version 2

     timers basic 3 18 18 24

     redistribute connected route-map CONN_RIP

     redistribute bgp 100 metric 5




    router bgp 100

     synchronization

     bgp router-id 150.7.5.5

     bgp log-neighbor-changes

     network 139.7.5.0 mask 255.255.255.0

     aggregate-address 139.7.0.0 255.255.0.0

     neighbor 150.7.6.6 remote-as 100

     neighbor 150.7.6.6 update-source Loopback0

     neighbor 150.7.6.6 next-hop-self

     neighbor 204.12.7.254 remote-as 54

     neighbor 204.12.7.254 route-map MATCH_AS54 in




    route-map CONN_RIP permit 10

     match interface FastEthernet0/0 FastEthernet0/1 Serial0/1/0 Loopback0

    route-map MATCH_AS54 permit 10

     match ip address 10

     set local-preference 50

    route-map MATCH_AS54 permit 20

     match ip address 11

     set local-preference 200





    Rack7R4#br

    BGP table version is 33, local router ID is 150.7.5.5

    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

                  r RIB-failure, S Stale

    Origin codes: i - IGP, e - EGP, ? - incomplete


       Network          Next Hop            Metric LocPrf Weight Path

    * i28.119.16.0/24   150.7.6.6                0    100      0 54 i

    *>                  204.12.7.254             0     50      0 54 i

    * i28.119.17.0/24   150.7.6.6                0    100      0 54 i

    *>                  204.12.7.254             0     50      0 54 i

    * i112.0.0.0        150.7.6.6                0    100      0 54 50 60 i

    *>                  204.12.7.254                   50      0 54 50 60 i

    *> 113.0.0.0        204.12.7.254                  200      0 54 50 60 i

    * i114.0.0.0        150.7.6.6                0    100      0 54 i

    *>                  204.12.7.254                   50      0 54 i

    *> 115.0.0.0        204.12.7.254                  200      0 54 i

    * i116.0.0.0        150.7.6.6                0    100      0 54 i

    *>                  204.12.7.254                   50      0 54 i

    *> 117.0.0.0        204.12.7.254                  200      0 54 i

    * i118.0.0.0        150.7.6.6                0    100      0 54 i

    *>                  204.12.7.254                   50      0 54 i

    *> 119.0.0.0        204.12.7.254                  200      0 54 i

    r i139.7.0.0        150.7.6.6                0    100      0 i

       Network          Next Hop            Metric LocPrf Weight Path

    r>                  0.0.0.0                            32768 i

    *> 139.7.5.0/24     139.7.45.5               2         32768 i

    Rack7R4#



    Don't see any requiremnts broken with this one!






  • Hi JJ,

       As i said in the other post, if you use the "unsuppress map" feature you need to send ONLY the aggregate, thus you need "summary-only".

    Good luck with your studies!

  • Hi C

    who was first...chicken or egg...

     

    wasn't the unsuppress used as a result of the summ only command...

     

    I used without the summ only and just the aggregate....

  • Hi JJ,

       So the developer wanted to solve task requirements by using "unsuppress map", thus he needed the "summary-only". There is no chicken egg in here.

    Good luck with your studies!

  • Hi C

     

    after I commented I read the other related post based on this task as well and you actualy explained thatside  that with Med the unsuppress not needed, which was exactly how I used in my solution

    the above posted scenario got me to think of a Chicken and egg scenario but hence the previous related post not true....

     

    thanks for the feedback...always appreciated!

     

  • I have to agree, this was one of the more interesting tasks. Good job INE and great job everyone who posted above.

    When I was doing it I make one wrong assumption that cause me quite some time to figure out how to solve it. My assumption was that the even and odd prefixes will have to be have a redundant path. For example if connection between R4-BB3 fails, odd prefixes should be rerouted over to R6-BB1 and vise versa. Based on this one assumptions I used a route-map to select even prefixes and INCREASE their LOCAL_PREFERENCE instead of filtering them. R4 and R6 both had the iBGP routes with their respective local preference. This caused me quite the issue with synchronization. Even thougth I had the higher local preference, each router would only take their eBGP path out. I had redistribution setup on R4 and R6 and nothing was working. This is where I realized reading the above posts, that by filtering (not allowing all prefixes, but only permitting Odd on R4 and even on R6) you are creating the IGP route required for synchronization.

     

    So my question next was, well how would you fix the scenario I created for myself, if this was another lab with these requirements, which in summary states, for even prefixes prefer the R4-BB3 path and for odd prefixes prefer the R6-BB1 path, if either connections fails provide redundancy.

     

    Thanks

     

    Tom

     

     

     

  • well how would you fix the scenario I created for myself, if this was another lab with these requirements, which in summary states, for even prefixes prefer the R4-BB3 path and for odd prefixes prefer the R6-BB1 path, if either connections fails provide redundancy.

     

     

    This worked for me:

    R4:
    router bgp 100
     bgp router-id 150.13.5.5
     distance 121 204.12.13.254 0.0.0.0 EVEN_FIRST
     network 139.13.5.0 mask 255.255.255.0
     agg 139.13.0.0 255.255.0.0
     neighbor 150.13.6.6 route-map TO_R6 out
     neighbor 204.12.13.254 route-map FROM_BB3 in

    router rip
     red bgp 100 route-map BGP>RIP

    ip prefix-list VLAN5 permit 139.13.5.0/24

    ip acce st ODD_FIRST
     permit 1.0.0.0 254.255.255.255

    ip acce st EVEN_FIRST
     permit 0.0.0.0 254.255.255.255

    route-map FROM_BB3 permit 10
     match ip address ODD_FIRST
     set local-preference 400
    route-map FROM_BB3 permit 1000

    route-map TO_R6 deny 10
     match ip address prefix VLAN5
    route-map TO_R6 permit 1000

    route-map BGP>RIP permit 10
     match ip address ODD_FIRST
     set tag 4100
     set metric 1
    route-map BGP>RIP permit 1000
     set metric 5

    R5:
    router rip
     no distance 109 
     distance 109 0.0.0.0 255.255.255.255 ODD_FIRST

    ip acce st ODD_FIRST
     permit 1.0.0.0 254.255.255.255

    router ospf 1
     red rip sub route-map RIP>OSPF

    router rip
     red ospf 1 route-map OSPF>RIP

    route-map RIP>OSPF permit 10
     match tag 4100
     set metric-type type-1
    route-map RIP>OSPF permit 1000

    route-map OSPF>RIP permit 10
     match tag 6100
     set metric 1


    R6:
    router bgp 100
     network 139.13.0.0 mask 255.255.255.0
     agg 139.13.0.0 255.255.0.0 sum
     neighbor 54.13.2.254 route-map FROM_BB1 in
     distance 111 54.13.2.254 0.0.0.0 ODD_FIRST

    router ospf 1
     red bgp 100 sub route-map BGP>OSPF
     

    ip acce st EVEN_FIRST
     permit 0.0.0.0 254.255.255.255

    ip acce st ODD_FIRST
     permit 1.0.0.0 254.255.255.255

    route-map FROM_BB1 permit 10
     match ip address EVEN_FIRST
     set local-preference 600
    route-map FROM_BB1 permit 1000

    route-map BGP>OSPF permit 10
     match ip address EVEN_FIRST
     set tag 6100
     set metric-type type-1
    route-map BGP>OSPF permit 1000

     

  • To go back a bit, the part everyone is overlooking is that, yes, while R4 is not in OSPF and it's redistributing into RIP, not OSPF, it *is* sending BGP prefixes to R6, since R6 is a BGP peer. These BGP routes have a bgp router-id attached to them. 


    When R6 learns the IGP routes, it learns them via OSPF, as it comes from R5. That means the IGP routes are going to have an OSPF router-id attached to them, that of R5. 

    So R6 is learning the prefixes two different protocols - via iBGP and via OSPF, and sync requires the OSPF RID to match the BGP RID, so the sync check fails, unless you alter the BGP RID on R4.

     

    I can get this to fail and work based on having the BGP router-id set if I change the BGP distance to 200 so that the BGP route doesn't take precedence over the Igp routes.  When I do this on R6 for example sh ip bgp 113.0.0.0 shows syncronized with a router-id of 150.1.5.5 but not if I remove it.  However w/out this it shows not syncronized either way and I'm guessing because the EBGP route is in the routing table so it therefore is not sync'd with an igp.

     

    Now this is where the task threw me, and why I didn't think to change the BGP RID. The eBGP routes will be preferred over the iBGP routes, so whether or not they're synced up is largely irrelevant, the only thing the internal routers care about are the IGP routes. By the time it hits a border router, the border router already has the prefix via eBGP, so even if the iBGP routes passed the sync check, they wouldn't be selected as best routes. 

    This task really needs to have a 'ensure the internal domain can still reach the prefixs if the links to BB1 or BB3 go down', because as stated, the task isn't concerned with redundancy. 

     

    However, as presented in the solution guide, if one of the BB links goes down, you still don't have redundancy, as the only source for those routes in the internal domain is R4 and R6, and the solution guide only has them redistributing even/odd as indicated, so if BB3's link goes down, R4 pulls the odd routes, R6 isn't advertising them, so the internal network loses access to the odd routes entirely. 

  • I would be grateful if somebody can answer my question that, will distribute list (inbound) prevent the aggregate route to be installed in routing table as well in addition to filtering the routes inbound from bgp neigbours:

    Please see below, where we have aggrigate in BGP table but it's not installed in routing table:

    Rack1R6#show running-config | sec bgp|prefix
    router bgp 100
     synchronization
     bgp router-id 150.1.6.6
     bgp log-neighbor-changes
     network 139.1.6.0 mask 255.255.255.0
     aggregate-address 139.1.0.0 255.255.0.0 summary-only
     neighbor 54.1.2.254 remote-as 54
     neighbor 150.1.4.4 remote-as 100
     neighbor 150.1.4.4 update-source Loopback0
     neighbor 150.1.4.4 next-hop-self
     distribute-list prefix NO_AGG_LOCAL in
     no auto-summary
    ip prefix-list NO_AGG_LOCAL seq 5 deny 139.1.0.0/16

    Rack1R6#show ip bgp 139.1.0.0/16      
    BGP routing table entry for 139.1.0.0/16, version 5
    Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(3) - next-hop mismatch)
      Advertised to update-groups:
            1    2
      Local, (aggregated by 100 150.1.6.6)
        0.0.0.0 from 0.0.0.0 (150.1.6.6)
          Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, best

    Rack1R6#show ip route 139.1.0.0 255.255.0.0
    % Subnet not in table
    Rack1R6#

    After Shutting down the ibgp neighborship with R4 and removing the distribute list:

    Rack1R6#show ip bgp 139.1.0.0 255.255.0.0
    BGP routing table entry for 139.1.0.0/16, version 13
    Paths: (1 available, best #1, table Default-IP-Routing-Table)
    Flag: 0x820
      Advertised to update-groups:
            2
      Local, (aggregated by 100 150.1.6.6)
        0.0.0.0 from 0.0.0.0 (150.1.6.6)
          Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, best

    Rack1R6#show ip route 139.1.0.0 255.255.0.0
    Routing entry for 139.1.0.0/16
      Known via "bgp 100", distance 200, metric 0, type locally generated
      Routing Descriptor Blocks:
      * directly connected, via Null0
          Route metric is 0, traffic share count is 1
          AS Hops 0

    Thanks very much!

Sign In or Register to comment.