bgp origin

Hi folks,

I'm stumped on this one - what makes the origin attribute so important?  It seems like a legacy piece of the puzzle that's still being treated as useful more than actually useful in my view.  I mean, 33% of the possible values (EGP) are never going to be seen in the wild under normal circumstances (which is a good argument for removing that piece entirely IMO).

It's used in path selection, though as far as I can tell, it's close to being a tie-breaker in that scenario, and seems arbitrary in any case - injected manually versus via redisribution, correct?  This is OK, since path selection in gneral after, say, AS path seems to me to be fairly arbitrary ways of just getting a route into the table so it can be used/advertized.

It is well-known and mandatory.  This is where I'm stuck.  Next-hop is obviously something that *must* be included in bgp routes since bgp routes have to use recursion (no interface listing in a bgp route).  AS path agan is obviously mandatory since a) it's the default loop prevention mechanism for bgp, and b) the recieving router has to know where the route came from.  But why origin?  What makes origin so important that it's considered *mandatory* that it is part of a bgp route?

Anyone have pointers?  Obviously this is mostly a curiosity type of question rather than a really important one, but I guess I'm at that point in my studies.

Comments

  • I guess this comes down to historic reasons. I'm sure there was a good thought behind the origin and I guess back then you had so few networks that it was no burden to put in a network statement when you had to announce networks.

    With the amount of networks used now it is easier to do redistribution and use a route-map to ensure you don't redistribute anything that should not be there, like RFC1918 etc.

    All the RFC says (1771) is this:

    5.1.1 ORIGIN

       ORIGIN is a well-known mandatory attribute.  The ORIGIN attribute
       shall be generated by the autonomous system that originates the
       associated routing information. It shall be included in the UPDATE
       messages of all BGP speakers that choose to propagate this
       information to other BGP speakers.

    So I guess the origin was used to indicate how trustworthy the information is, did it come from inside the AS (well known) of from some other source. It is a bit weird that if you redistribute from your own IGP that it is considered to be incomplete.

    The reason they don't remove EGP is probably because then they would have to modify the code and that would affect a lot of systems.

  • Great info Daniel.....

    I would think that the reasoning behind IGP redistribution showing up as incomplete is that you really aren't able to know "exactly" where that particular prefix was injected into the network via the IGP, although I don't think that information is pertinent to the importance of the origin attibute.....if an engineer is allowing the prefix to be imported into BGP, then they are "vouching" for the reliability of the NLRI.....

     

    warjack

  • Hi Daniel,

    Thanks for the reply!  I did look at the RFC as well as Internet Routing Architectures and Cisco docs, but most of what's said in any of them is more akin to mantra than explaination, beyond what e/i/? each mean.

    I guess I'm going to assume that it was an important part of the migration from EGP to BGP, and remains as a legacy piece of the puzzle that can be used as a "nerd knob" to tweak bestpath at this point.  I suppose it could be useful to know that a route had been injected via redistribution if a certain AS was well known for accidentally leaking routes, and their peers were well known for having lax filters, or something like that.

  • peetypeety ✭✭

    It's got historic meaning, but also gains meaning in big networks who are peering (in the netgeek true sense of the word) with big networks.  It's an interesting cost game.  Let's say you have a website on AT&T in San Francisco, and a dialup user on Level3 in New York City.  When the eyeballs issue an HTTP request, L3 will likely hand the request to AT&T at the closest peering point they share, which might be NYC or WashDC (since the closest exchange has the lowest IGP cost).  In turn, AT&T has to carry the request all the way through their network to SFO.  In response, AT&T will likely hand the response back to L3 at the closest peering point they share, which might be SFO or LAX (again due to lowest IGP cost).  As a result, L3 has to carry the response all the way through their network to NYC.  Each network took care of a portion of the long-haul, and that's how they often like it.  Each of the networks probably "squashes" MED over a peering connection (resets to 0 or some other arbitrary value), and may "enforce" limits on AS path prepending, to make sure they only have to carry traffic one way.

    The game, then, is to fiddle with origin code.  In this scenario, L3 could fiddle with origin code so AT&T preferred to carry the traffic back to NYC/WashDC before handing it to L3, thereby dumping the long-haul "cost" onto AT&T, at great advantage to L3.  I'd guess this is about the only typical use of this attribute.

  • Thanks Peety!

  • Very well explained Peety... You have very strong practical hand on BGP.

  • Yes, it's called "hot potato" and "cold potato" routing. Pretty funny terms, and appropriate :-) Hot potato = I will get it off my hands as soon as possible and hand it over to your network at closest point. Cold potato = I will carry it myself to some location closest to your custoemr so you don't have to carry it over whole network (ie. I may have better long haul connections and bugger pipes so we agreed we'll do it this way).

    Obviously all of this is based on agreement between any peering networks. They can honor MED, use communities to set Local Preference within network, even to influence which upstream provider you would like them to use for your traffic and such. And it's always a matter of trust. If you want to game the system a bit or make minuscle decisions, you can use tricks like that.

    Back to ORIGIN code: If you look into any public roter looking glass, you can see some routes actually do have e as origin. Surprised me a little bit too, but what peety wrote makes actually pretty good sense.

    By the way I think Juniper by default sets all their BGP routes as ?. I heard this is so they have automatically lowest priority, and if you want routes to be perceived otherwise you have to "touch them" and set it manually. That's the philosophy there, they are introducing you to have more control over what's going on. Service Providers love to have more control over everything [;)]

  • Yes, these are terms are often used in a day-to-day basis when working on an SP. Here is a cool link about cold/hot potato routing:

    http://static.usenix.org/event/usenix02/full_papers/subramanian/subramanian_html/node28.html

    HTH

    Good luck!

  • Back to ORIGIN code: If you look into any public roter looking glass, you can see some routes actually do have e as origin. Surprised me a little bit too, but what peety wrote makes actually pretty good sense.

    I'm going to assume that these have been changed via route-map rather than actually being injected via EGP, but it's becoming more and more apparent from reading these boards I know even less than I thought I did about some/many things.

    I do understand the concept of exchanging traffic based on cost of peering agreements or badnwidth available between sites, though I haven't ever been in a situation where that was a consideration.  I'm usually trying to get traffic to leave/enter my network based on either which circuit is being crushed the worst, or which upstream is having issues reaching certain prefixes.  I hadn't heard the "potato" terminology before, though - makes sense though.

  • Yes, these are terms are often used in a day-to-day basis when working on an SP. Here is a cool link about cold/hot potato routing:

    http://static.usenix.org/event/usenix02/full_papers/subramanian/subramanian_html/node28.html

    HTH

    Good luck!

    Cool - I'll check that out.  Man, usenix - that brings back some memories.

  • peetypeety ✭✭

    For ORIGIN, I'd think it's rare that a prefix is originated in more than one place on most networks, with the exception of aggregate prefixes.  If the prefix is coming from one place, it'll always have the same origin code unless modified later via route-map.  I would normally set it explicitly whenever I was originating the route, normally by redistribution.

    Sounds like you need more bandwidth, buddy!  I remember those days.

Sign In or Register to comment.