rfc4271 ORIGIN/path of default route, should the value be 0 or 2?
Howdy, I am using a multi-vendor network and validating the inter-operability. When I announce a default route to a BGP peer using default-originate applied to the peer group/neighbor configuration: in vendor A that route is sent with ORIGIN 0 (internal) in vendor B that route is sent with ORIGIN 2 (Unknown) Downstream it looks like this: Network Next Hop Metric LocPrf Weight Path * i 0.0.0.0 192.168.27.1 100 0 ? *>i 192.168.25.1 0 100 0 i * i 192.168.27.2 100 0 ? I don't believe that it has a functionality impact but I would like to know which one you think follows the RFC more closely. https://tools.ietf.org/html/rfc4271 thanks, -Drew
Hey,
I don’t believe that it has a functionality impact but I would like to know which one you think follows the RFC more closely.
Debatable, but: Internal is more accurate if you redistribute default from routing protocol, such as static. Unknown is more accurate if you just generate it in BGP, without having it. Functional difference is best-path selection algorithm. Origin can be used to bypass hot-potato policies of peers, by forcing them to carry packets longer inside their network. If your policy is hot-potato, then you should reset Origin on received external routes. -- ++ytti
Debatable, certainly, as the Origin attribute should probably be considered as dead/obsolete and therefore it is probably a good practice to always set/reset it to internal. A number of networks already do this (including level3 by example). After all, the origin attribute was only designed to allow a «smooth» transition between EGP and BGP (that is, it was useful during a few years for a few networks several decades ago).
Le 7 juil. 2020 à 15:47, Saku Ytti <saku@ytti.fi> a écrit :
Debatable, but: Internal is more accurate if you redistribute default from routing protocol, such as static. Unknown is more accurate if you just generate it in BGP, without having it.
Functional difference is best-path selection algorithm. Origin can be used to bypass hot-potato policies of peers, by forcing them to carry packets longer inside their network. If your policy is hot-potato, then you should reset Origin on received external routes.
Okay, In my use case it's just a default route being distributed by a router that has the full routing table to an access router in the same ASN. It's not being sent to other ASNs or anything of that sort. I was just curious as to why Cisco sets it to internal and Arista sets it to invalid. Thanks, -Drew -----Original Message----- From: NANOG <nanog-bounces+drew.weaver=thenap.com@nanog.org> On Behalf Of Olivier Benghozi Sent: Tuesday, July 7, 2020 12:47 PM To: nanog@nanog.org Subject: Re: rfc4271 ORIGIN/path of default route, should the value be 0 or 2? Debatable, certainly, as the Origin attribute should probably be considered as dead/obsolete and therefore it is probably a good practice to always set/reset it to internal. A number of networks already do this (including level3 by example). After all, the origin attribute was only designed to allow a «smooth» transition between EGP and BGP (that is, it was useful during a few years for a few networks several decades ago).
Le 7 juil. 2020 à 15:47, Saku Ytti <saku@ytti.fi> a écrit :
Debatable, but: Internal is more accurate if you redistribute default from routing protocol, such as static. Unknown is more accurate if you just generate it in BGP, without having it.
Functional difference is best-path selection algorithm. Origin can be used to bypass hot-potato policies of peers, by forcing them to carry packets longer inside their network. If your policy is hot-potato, then you should reset Origin on received external routes.
participants (3)
-
Drew Weaver -
Olivier Benghozi -
Saku Ytti