From: Bill Lijewski (bill@eccie.com)
Date: Fri Apr 02 2004 - 15:31:49 GMT-3
There are two checks that an iBGP route goes through before it gets to
any of the attributes such as WEIGHT, LOCAL PREFERENCE, etc... The two
checks it must first go through are:
1) The next hop address must be reachable.
In other words if the iBGP router doesn't see the next hop of a BGP
route in it's IGP table it will not mark the BGP route as a best route
and it will not show up in the IGP table. This makes sense, if the
local iBGP router can't reach the BGP routes next hop why would it mark
it as a best route and send it to someone? Let's take a look at the
'show ip bgp' output of a iBGP router:
BGP table version is 303, local router ID is 204.4.7.1
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i3.3.3.0/24 150.10.4.1 0 100 0 30 i
This router sees 150.10.4.1 as the BGP next hop for the 3.3.3.0/24
network. If that 150.10.4.1 network wasn't in the routers IGP table the
3.3.3.0/24 network wouldn't be marked as a best '*>' route.
If the 150.10.4.1 network wasn't in the IGP routing table there are a
couple of ways to fix this. eBGP automatically changes the next hop,
where iBGP does not change the next hop. If it's allowed we could place
the network we see as the next hop into an IGP routing protocol so we
would see it in the local IGP table. However there is a good chance
that wouldn't be allowed so we could use the 'next-hop-self' command.
This command would be configured on the router sending this route to us
- this would basically tell us to use them as the next hop (which should
be reachable).
2) With Synchronization enabled there must be an exact match for the BGP
route in the IGP table.
eBGP doesn't check for synchronization so it will place the route into
the BGP table as a best route without finding a matching route in the
IGP table. However, when this route gets sent to an iBGP neighbor, that
iBGP neighbor will check for a match in the IGP table. If there isn't a
match in the IGP table it will NOT mark the route as a best route.
There must be a match in the IGP table, and if it's OSPF, the BGP and
OSPF Router ID's of the origin must match.
There is no way to get around either of these checks, and the route will
not be placed into the BGP table as a best route if either of these
checks fails.
- Bill Lijewski
CCIE#8642
Network Learning Inc
5 Day R&S CCIE Bootcamp Instructor
http://www.ccbootcamp.com
bill@eccie.com
-----Original Message-----
From: Edwards, Andrew M [mailto:andrew.m.edwards@boeing.com]
Sent: Friday, April 02, 2004 10:09 AM
To: Packet Man; bill@eccie.com; gladston@br.ibm.com;
ccielab@groupstudy.com
Subject: RE: BGP and OSPF RID [bcc][faked-from][bayes]
I wanted to ask one question for my own edification... I noticed an eBGP
speaker will put the routes learned via eBGP into its routing table.
Then, the eBGP speaker will tell its iBGP counterparts about those eBGP
learned routes. These routes will be put into the local routing table
of an iBGP speaker, with synchronization ENABLED, as long as the eBGP
learned route has a next-hop address that is reachable by the iBGP
speaker. If the next-hop is not reachable, then it doesn't go into the
BGP table, and therefore, the local IP routing table.
At least that's what I saw... And that's why using route-maps for these
eBGP speakers becomes important for BGP route redistribution with
synchronization enabled.
Can someone confirm my understanding... ?
Thx
andy
-----Original Message-----
From: Packet Man [mailto:ccie2b@hotmail.com]
Sent: Thursday, April 01, 2004 2:28 PM
To: bill@eccie.com; gladston@br.ibm.com; ccielab@groupstudy.com
Subject: RE: BGP and OSPF RID [bcc][faked-from][bayes]
Bill,
You have some of the best written and most informative and insightful
posts
I've seen here on GS. I always learn something new whenever I read your
posts even when it's on a topic I'm very knowledgable about. So, I hope
you'll keep sending in your thoughts.
thanks, pm
>From: Bill Lijewski <bill@eccie.com>
>Reply-To: Bill Lijewski <bill@eccie.com>
>To: gladston@br.ibm.com, ccielab@groupstudy.com
>Subject: RE: BGP and OSPF RID [bcc][faked-from][bayes]
>Date: Thu, 1 Apr 2004 13:44:57 -0800
>
>Synchronization only comes into play for iBGP routes. With
>synchronization on the router will check its IGP table for all iBGP
>routes it learns to make sure that it has a matching entry before it
>will ever put the route into its BGP table as a best route.
>Synchronization does not check for a match in the IGP table for eBGP
>routes. If no match is found in the IGP table for the iBGP routes they
>will not be marked as best, and the routes will not be passed to any
>other BGP neighbors.
>
>There is one extra step that BGP goes through for iBGP routes when
>synchronization is on and OSPF is the underlying IGP. BGP will check
>for a matching route in the IGP table, if one is found it will check to
>see which IGP protocol is running. If the router is running OSPF as
>its IGP, BGP will check and make sure that the origin of the routes for
>both OSPF and BGP are the same. In other words BGP will make sure that
>the OSPF and BGP router IDs of the source of the route match before it
>will put it into the BGP table.
>
>You can check these Router ID origins with the following two commands:
>
>For the OSPF route: show ip route x.x.x.x
>
>For an example we can see what the origin of the 210.10.10.0/24
>network:
>
>Routing entry for 210.10.10.0/24
> Known via "ospf 1", distance 110, metric 1, type extern 2, forward
>metric 10
> Last update from 172.168.1.2 on Ethernet0, 1d03h ago
> Routing Descriptor Blocks:
> * 172.168.1.2, from 5.5.5.5, 1d03h ago, via Ethernet0
> Route metric is 1, traffic share count is 1
>
>The second line up from the bottom is the important one. It shows
>'from 5.5.5.5', 5.5.5.5 is the OSPF origin ID for this route.
>
>
>For the BGP route: show ip bgp x.x.x.x
>
>Again we can take a look at the origin of the 210.10.10.0/24 network:
>
>BGP routing table entry for 210.10.10.0/24, version 2
>Paths: (1 available, best #1, table Default-IP-Routing-Table)
> Advertised to non peer-group peers:
> 192.168.2.2
> Local
> 172.168.1.2 from 5.5.5.5
>Origin IGP, metric 0, localpref 100, valid, internal, synchronized,
>best
>
>Again the second line up from the bottom shows 'from 5.5.5.5', 5.5.5.5
>is the BGP origin ID for this route.
>
>In this case both the BGP and the OSPF origin Router ID's match so this
>route could be placed into the BGP table as a best route.
>
>
>- Bill Lijewski
>CCIE#8642
>Network Learning Inc
>5 Day R&S CCIE Bootcamp Instructor
>http://www.ccbootcamp.com
>bill@eccie.com
>
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>gladston@br.ibm.com
>Sent: Thursday, April 01, 2004 1:25 PM
>To: ccielab@groupstudy.com
>Subject: BGP and OSPF RID [bcc][faked-from][bayes]
>Importance: Low
>
>I remember to see a problem related to OSPF and BGP RID, redistribution
>and Route Refletor.
>
>Any help on where it is on the DOCCD or cisco.com?
>
>_______________________________________________________________________
>Please help support GroupStudy by purchasing your study materials from:
>http://shop.groupstudy.com
>
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
>
>_______________________________________________________________________
>Please help support GroupStudy by purchasing your study materials from:
>http://shop.groupstudy.com
>
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon May 03 2004 - 19:48:41 GMT-3