BGP: prefer locally/self originated paths

Hi folks,

I'm having a hard time wrapping my head around #3 (or #4, depending on whether you consider "reachable next hop") in the path selection algorithm.  Some sources cite "locally" as being local to the BGP speaker in question, while others cite it as being local to the AS/confed, originated via a netowrk statement or aggregate.  I have to admit I'm kind of fuzzy on iBGP in general, so that may be part of the issue - I tend to view it as "last recourse" for any local routing since obviously just making it into the BGP table doesn't gurantee making it in to the routing table.  My simplistic view of iBGP is that it's mostly useful for telling BGP speakers which exit to use when *leaving* the local AS, so it's surprising to me that local AS announcements would factor in towards the top of the list.  Can anyone either point me to some good documentation/discussion of this point, or explain why this would land as #3 on the path selection list?

Sorry in advance if this is blindingly obvious and I'm just missing it.

Comments

  • Hi,

    Weight is cisco specific so ignore that also. Now locally originated routes come at #2. For locally originated routes BGP next hop is 0.0.0.0 ie itself. So the route can be reached using IGP within AS. So question remins why local-preference comes #1?, it to reach external to AS destinations. Also one does not configure network statement with route contained in another AS, network statement always need to configure route contained in self AS. So self next hop routes come at very beginning of route selection algorithm.

    This is what I think, correct me if wrong.

    Thanks,

    Dinesh

  • Hi dineshg, thanks for the reply!  I suppose I have a very SP-centric, non-transit-AS-centric view of BGP.  I work with BGP quite a bit for my day job, but I do very few iBGP gymnastics.  In general, as you mention with localpref, my main concern is either which exit outbound traffic is taking, or which one inbound traffic is taking.  I'm depending on my IGP to get my traffic from my customers to my edge, at least as far as I understand things - I'm 99% sure that none of my prefixes show up in my routing table as BGP routes.

    This still leaves me wondering in what scenario I'd want to make a bestpath decision based on a locally originated prefix.  Obviously I don't want to hear my own prefix from any of my EBGP neighbors, and filter against that (and also depend on BGP to verify my own AS doesn't appear in the AS path).

  • Hi qqabdal, thanks for the reply!

    Unfortunately, "Prefer the path that was locally originated via a network or aggregate BGP subcommand or through redistribution from an IGP.  Local paths that are sourced by the network or redistribute commands are preferred over local aggregates that are sourced by the aggregate-address command" doesn't really mean anything to me, which is why I'm asking the question.

    Obviously I can remember the rule, but like I say, I'm having a hard time understanding where this would be applicable.  A BGP-only network?  Or is this simply a way to make certain that locally sourced routes make it in to the BGP table early on in the process?  I'm probably just being stupid since so far I haven't had any luck with my google fu.

  • Hi,

    Consider this case.  R1-----R2-----R3 . All in AS 123. Use RIP as IGP. Every router has lo0. R3 has lo1 in addition to lo0. RIP runs on all interfaces on all routers. Establish ibgp session between R1 and R3. R3 has loopback1 33.33.33.33/32 and use network 33.33.33.33 mask 255.255.255.255 in R3. Also use network 33.33.33.33 mask 255.255.255.255 in R1. Now R1 has 2 routes to 33.33.33.33/32 in "show ip bgp" one self originated and one through iBGP from R3. R1 selects self originated route over iBGP route.

    Regards,

    Dinesh

  • peetypeety ✭✭

    Here's my key trigger for that question: if 'sh ip bgp a.b.c.d/e' shows you a path with 'sourced', it's local.  Else, it's not.

    Edge1#sh ip b 10.59.1.1 
    BGP routing table entry for 10.59.1.0/24, version 15
    Paths: (2 available, best #1, table Default-IP-Routing-Table)
      Advertised to update-groups:
         2        
      Local
        0.0.0.0 from 0.0.0.0 (10.255.0.9)
          Origin incomplete, metric 200, localpref 100, valid, sourced, best
          Community: 65100:10000
      Local
        10.255.0.10 (metric 1017) from 10.255.0.10 (10.255.0.10)
          Origin incomplete, metric 2000, localpref 100, valid, internal
          Community: 65100:10000

    Next-hops are reachable.

    Weights are 0 for both (I set weight to 0 in the redistribution process)

    Local-pref is 100 (default) for both.

    Upper path wins because it's sourced locally on Edge1.

     

  • Sweet - thanks!  That's more or less exactly what I was asking about.  I think I may have been asking the question poorly.

  • peetypeety ✭✭

    I have to admit I'm kind of fuzzy on iBGP in general, so that may be part of the issue - I tend to view it as "last recourse" for any local routing since obviously just making it into the BGP table doesn't gurantee making it in to the routing table.  My simplistic view of iBGP is that it's mostly useful for telling BGP speakers which exit to use when *leaving* the local AS, so it's surprising to me that local AS announcements would factor in towards the top of the list.  Can anyone either point me to some good documentation/discussion of this point, or explain why this would land as #3 on the path selection list?

    I view BGP as a "last-hop" routing protocol, and view the IGPs as a "next-hop" protocol, but I came from the Service Provider world so I may simply see it differently.  Let's say you have two core routers and eight other "perimeter" routers of various sizes and roles, each connecting to one or both core routers.  If you BGP them all together (full mesh, route reflectors, confederations - however you want to do it) and IGP them all together, BGP will tell the perimeter routers which perimeter router to use as the exit for any given packet, and then the IGP will tell the routers what path to take through the core to get there.

    In this case, "local" (as explained previously) means: in the eyes of BGP, this network is RIGHT HERE.  It might be 'connected', it might be 'static', it might be IGP-learned, or it might be aggregate, but "I" know that it's reachable right here.  Let's assume it's a connected route (which is the case for the example output I showed earlier).  If a packet arrives on Edge1 for 10.59.1.2, why would Edge1 choose to send it elsewhere if Edge1 has a connected route to 10.59.1.2?  That's why BGP prefers the locally-originated paths.

    Whenever I can get away with inserting a dynamic routing protocol (or two: I'm a big fan of IGP on infrastructure links, and BGP to carry the LAN routes and external routes), my standard approach is "put every relevant route into the routing protocol, and let every router learn about it".  If the whole network knows where the whole network is, the whole network will run efficiently.  If I can do IGP+BGP, it's going to be OSPF (manual cost control) on infrastructure links and loopbacks, and BGP between all of the routers (with route reflectors where appropriate).  I redistribute connected and static routes into BGP, and let BGP share them with everyone else.  The redistribution is done with a route-map, along the lines of:

    !

    ip prefix-list conn-bgp-ignore p<loopback-subnet>/N le 32 !(repeat as needed for infrastructure subnets that are in the IGP)

    ip prefix-list conn-bgp-backup p 0.0.0.1/32

    !

    route-map conn-bgp deny 10

     match ip address prefix conn-bgp-ignore

    !

    route-map conn-bgp permit 20

     match ip address prefix conn-bgp-backup

     set weight 0

     set metric 2000

     set community (secret-code)

    !

    route-map conn-bgp permit 30

     set weight 0

     set metric 200

    !

    router bgp ASN

     redist conn route-map conn-bgp

    !

    end

    -----------------

    This provides an easy hook to exempt routes from being redistributed if that's necessary somewhere.  It then provides an easy hook to mark a route as backup (great with HSRP).  Everything else is then automatically redistributed.  Since I can't remember if a nonexistant prefix list becomes allow-all or deny-all, AND so that people can see how to write the conn-bgp-backup prefix list, I create a dummy entry that's highly unlikely to ever exist in production.

  • [QUOTE]I view BGP as a "last-hop" routing protocol, and view the IGPs as a "next-hop" protocol[/QUOTE]

     

    Yeah. that's a better way of saying what I was getting at.

    I tend to try to keep my BGP table as sparse as possible (which is easy now that I'm only announcing a single /18 and no longer have any downstream BGP peers) but being self taught, "the router guy" for a small ISP, and working in an envronment that's largely driven by the motto "screw planning and process, it's easier to regret than think ahead" I tend to be gun shy.  I've seen, been the cause of, or heard of too many horrible leak disasters to feel comfortable with redistributing routes into BGP.

    Thanks for the replies!

  • peetypeety ✭✭

    In a public scenario, I use BGP to carry all of the customer routes around the network.  I then modify the redistribution route-map like this:

    !

    route-map conn-bgp d 10

     match ip address prefix conn-bgp-ignore

    !

    route-map conn-bgp p 20

     match ip address prefix conn-bgp-export-backup

     set metric 2000

     set community ASN:ABCDE

    !

    route-map conn-bgp p 25

     match ip address prefix conn-bgp-export

     set metric 200

     set community ASN:ABCDE

    !

    route-map conn-bgp p 30

     match ip address prefix conn-bgp-backup

     set metric 2000

     set community no-export ASN:ABCDE

    !

    route-map conn-bgp p 35

     set metric 200

     set community no-export ASN:ABCDE

    !

     

    In "ASN:ABCDE", the A after : is used to encode what kind of route it is (1=customer, 2=us, 3=external).  On egress, only ASN:1.... and ASN:2.... are permitted, and of course routes marked no-export won't go out anyway.  This keeps the IGP super lean and efficient.

     

  • So, back to this...

    I had an epiphany a while back which some might call a blinding flash of the obvious.  All things being equal, as a router, the main purpose of selecting a locally originated route is for best-path selection, so you can tell neighbors about your own route (only share best paths).  Again, blindingly obvious, but I think it was the piece I was missing.

    That said, and this is something I believe Peety alluded to up above where he mentions setting weights to 0, when left to "natural" path selection, I can't see how Locally Originated will ever influence route selection since a "sourced" route has a weight of 32k and will be used as a best path right off the bat.

    Once upon a time, I felt like I knew BGP pretty well, but the more I hang around here, the more obvious it is that I have a moderate grasp at best.  I imagine that this is going to be a repeatedly re-learned lesson as I continue studying...

  • peetypeety ✭✭

    You're right: under basic circumstances, weight 32768 on locally-originated paths wins right away.

    My advice: "think like a router" and "just think about one prefix at a time" (because if you think like a router, you're only going to think about one prefix at a time.  Slow the process WAY down in your head, and imagine that AS100 learns a route from AS200, then imagine that AS100 learns another path to that same route from AS200 over another EBGP session.  The routers in AS100, one by one, are all going to have to make best-path decisions, and possibly change their IBGP announcements, based on the outcome of those decisions.

    Imagine: AS200R21---AS100R11--AS100R12--AS100R13---AS200R22 (three routers in AS100 speaking IBGP with each other, and two of them have connections to AS200).  As R22 announces another path to whatever route R21 announced, R13 will recalculate (and will probably prefer the path to R22 because it's EBGP, courtesy of step 7 in the PSA).  Assuming it does prefer the EBGP path to R22, it'll then announce that path to R12.  R12 will have to recalculate, and probably will stick with R21/R11 because it's older, courtesy of step 10 in the PSA).

    --------------------

    Why do I reset weight to 0?  Because I'm "addicted" to MED.  I feel like it's an ignored knob, and if there are multiple exit points, I should use the multi-exit discriminator to "discriminate" between them.  In the example above, the local path won by step 3, but the MED is obvious to me as an intention to send traffic towards the primary.  On the "sister" router, the locally-originated route still wins:

    Edge2#sh ip b 10.59.1.1
    BGP routing table entry for 10.59.1.0/24, version 4
    Paths: (2 available, best #2, table Default-IP-Routing-Table)
      Advertised to update-groups:
         2        
      Local
        10.255.0.9 (metric 1017) from 10.255.0.9 (10.255.0.9)
          Origin incomplete, metric 200, localpref 100, valid, internal
          Community: 65100:10000
      Local
        0.0.0.0 from 0.0.0.0 (10.255.0.10)
          Origin incomplete, metric 2000, localpref 100, valid, sourced, best
          Community: 65100:10000

    But on the core router(s), the path to Edge1 wins on MED:

    Core1#sh ip b 10.59.1.1
    BGP routing table entry for 10.59.1.0/24, version 592
    Paths: (2 available, best #1, table Default-IP-Routing-Table)
      Not advertised to any peer
      Local
        10.255.0.9 (metric 509) from 10.255.0.9 (10.255.0.9)
          Origin incomplete, metric 200, localpref 100, valid, internal, best
          Community: 65100:10000
      Local
        10.255.0.10 (metric 509) from 10.255.0.10 (10.255.0.10)
          Origin incomplete, metric 2000, localpref 100, valid, internal
          Community: 65100:10000

    I think another part of it is that I don't like weight, because I learned a valuable lesson 13 years ago with OSPF: all routers must have an identical view of the network.  That's how I try to make BGP work, and weight messes with that.

Sign In or Register to comment.