12-26-2011 04:52 PM - edited 03-04-2019 02:45 PM
Hi everyone
Please consider the following case:
R3----- Ibgp--------R1-------Ebgp------R2
neighbor 199.199.199.2 ( EBGP peer of R1)
neighbor 200.200.200.3 ( Ibgp peer of R3)
R1 is receiving prefix 2.0.0.0/8 from EBGP peer and also from IBGP peer.
All the path attributes are using default values.
R1 has to break the tie using best path algorithm.
Let say R1 has already checked other path attributes and now considering " Origin" path attribute to break this tie.
R1#show ip bgp
BGP table version is 3, local router ID is 200.200.200.1
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
r 2.0.0.0 199.199.199.2 0 0 2 i
r>i 200.200.200.3 0 100 0 i
Origin codes are:
i which indicates prefix is introduced using network command into bgp
? which indicates prefix is introduced using " redistribution" into bgp
e which I want to understand.
Clearly, R1 has chosen prefix from ibgg peer because of orgin code i
The questions are:
if R1 receives a prefix 2.0.0.0/8 from its EBGp peer R2, will this prefix be regarded as ebgp route?
Will such prefix have orgin code" e" even though the origin attribute shows " i' ?
Will ebgp between R1 and R2 considered as egp?
will prefix received via ebgp at R1 be viewed as prefix injected from egp into bgp?
thanks and have a nice week.
Solved! Go to Solution.
12-26-2011 05:06 PM
No that route will not have an origin code of e. The semantics here are a bit confusing because in our modern environment the protocol that would seem to be logically associated with origin of e is EBGP. But in fact the origin code of e is associated with the protocol of EGP which is an old protocol whose name is Exterior Gateway Protocol. It is not used any more and therefore you will not see any prefixes in a modern BGP table with the e origin code because the old EGP protocol is not used any more - but the origin code still remains in the protocol definition of BGP.
So in your example both advertisements have the same origin code and the choice of prefix is based on something other than origin code.
HTH
Rick
12-26-2011 08:55 PM
No, the tie breaker on this example is the AS_PATH attribute.
The first entry contains one AS in the path while the second entry is iBGP learned with 0 AS in the path.
Local Pref defaults to 100 even if it isn't shown as a value.
Regards,
Edison
12-26-2011 05:06 PM
No that route will not have an origin code of e. The semantics here are a bit confusing because in our modern environment the protocol that would seem to be logically associated with origin of e is EBGP. But in fact the origin code of e is associated with the protocol of EGP which is an old protocol whose name is Exterior Gateway Protocol. It is not used any more and therefore you will not see any prefixes in a modern BGP table with the e origin code because the old EGP protocol is not used any more - but the origin code still remains in the protocol definition of BGP.
So in your example both advertisements have the same origin code and the choice of prefix is based on something other than origin code.
HTH
Rick
12-26-2011 05:41 PM
Hi Richard
Network Next Hop Metric LocPrf Weight Path
r 2.0.0.0 199.199.199.2 0 0 2 i
r>i 200.200.200.3 0 100 0 i
"So in your example both advertisements have the same origin code and the choice of prefix is based on something other than origin code"
Is that something " local prf" in my example ?
thanks and have a great evening. .
12-26-2011 08:55 PM
No, the tie breaker on this example is the AS_PATH attribute.
The first entry contains one AS in the path while the second entry is iBGP learned with 0 AS in the path.
Local Pref defaults to 100 even if it isn't shown as a value.
Regards,
Edison
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide