BGP Origin, what it means to be i,e,?

BGP has a number of metric affecting values, one of the most often ignored is origin although it can have a serious effect on your routing table. Imagine getting two routes from two eBGP neighbors. ISPA is connected to CUSTOMER_Z using OSPF and redistributes those learned networks into BGP then advertises those to it's other upstream peers. ISP_B on the other hand is also connected to the same CUSTOMER_Z however ISPB decides to bring those OSPF networks into the BGP RIB using the 'network' statement. The upstream BGP peers will receive two routes into their RIB one with an origin of i (the one from the ISP_B) and one with origin ? (the one from ISP_A).

BGP uses a number of 'tiebreakers' to decision the best route to a destination and here are the first 5; Weight (Cisco proprietary), Local Preference, AS-PATH length, Origin, MED. So origin comes right after AS-PATH length and actually is the second highest decision maker for your outbound traffic...it really matters.

So in this tech guide we're going to build a small 3 mode network. The diagram below shows two BGP autonomous systems. 65001 contains R1 and R2 and they are connected with the network 12.1.1.0/24. R3 is in another AS with number 65002. The network between R2 and R3 is 13.1.1.0/24

Here is the output from R1 showing first the ip routing table and then a 'show run' for the interface connected to R2

Here is the same output for R2. Note that R2 is connected to R1 via Fa0/0 and R3 via Fa0/1

Finally the same output for R3

OK so we have IP comms between R1, R2 and R3. Now we're going to configure the BGP relationships.

First we'll add the neighbor statement on R1 for R2 (remember we already enabled the BGP process by issuing the 'router bgp 65001' global configuration command.

Now we do the same for the other side of this neighborship on R2 pointing to R1

Note that both have the same AS# because they are iBGP neighbors. We see now that the neighbor relationship is 'Established'

OK so now lets setup the eBGP relationship between R2 and R3. Firstly on R2

Now on R3

Note the difference in AS# between that configured in the 'router bgp' and the 'remote-as' this is an eBGP relationship. We get this console message on R2 - the neighborship is Established.

So lets create our first 'network' to advertise via BGP from R3. We'll just use a loopback interface, here it is loopback0.

We bring this into BGP using the 'network' statement. 

Now on R2 we can see that R3 has indeed sent us a route for 150.1.1.0/24. Notice the origin for the route is 'i' or internal. Thats because we brought the route into the BGP RIB (Routing Information Base) using the 'network' keyword.

So what happens if we bring the network in via a redistribution? We'll create another loopback interface on R3 called loopback1 and redistribute that connected interface into the BGP RIB.

Firstly the interface configuration

Now we add the necessary configuration to the bgp routing process. Firstly we need to be careful here. simply redistributing all connected interfaces will also bring our loopback 0 interface in...so lets use a route-map. We'll match the network for loopback 1 using an access-list

Here is the access list (we could use the 'host' keyword instead of 0.0.0.0)

Now the route-map. We're matching access-list 1 which is 200.1.1.0/24 which is the network we configured for interface loopback 1. Any other match is denied and dropped i.e. it won't be redistributed.

So lets have a look at the routing table on R2 to see if we now how two routes, the first from 150.1.1.0 and now a second for 200.1.1.0.

We do! Thats great. Now look at the origin. The first was an 'i' for internal which you remember was brought in using the 'network' keyword. Now the new network 200.1.1.0 has an origin of '?' which means incomplete. The reason for this is we don't know the source of the route so our knowledge of it's origin is...well incomplete. All we know is that someone brought it in from somewhere.

So there is one more origin type and that is 'e' or EGP. Now EGP is a legacy protocol and I've never come across it. To create the 'e' origin type therefore we'll have to 'fudge' it. We're going to use a route-map again to set this.

First lets create another loopback interface on R3 for this EGP candidate route.

OK, so now lets edit the existing route-map to add in our EGP configuration. What we'll do is again using an access-list match the interface lo2. If it matches then change the origin to e and set the source AS# for the EGP to 65003.

OK, now thats done we'll wait for a while till the BGP routes settle (or we can force it with a 'clear ip bgp *' at either side of the peering).

There we go...all three origin types. If these were duplicated routes learned from different sources with the same AS_PATH length we'd choose i first, then e then ?.

So what about R1? You're right we didn't even use this yet...lets take a look at it's routing table...

Nothing? Of course - is the next hop in my routing table? No of course not so the route goes into the BGP RIB but is inaccessible. So we need to set the 'next-hop-self' on R2 to change the next hop to R2's fa0/0 interface.

OK lets see the routing table now.

Looks good - of course R3 has no way of knowing how to get to 12.1.1.0/24 yet but you know how to do that now right? Of course you do...

Thanks for reading.