From: Omer Ansari (omer@xxxxxxxxxx)
Date: Thu Aug 22 2002 - 04:27:31 GMT-3
Brian,
thanks for the excellent explanation. Clears up a lot of things.
On Wed, 21 Aug 2002, Brian McGahan wrote:
> Omer,
>
> Actually, origin code is another completely unrelated attribute
> in this case. You're confusing the origin code with the status code of
> internal or external. Take the following BGP table output:
>
> router#sh ip bgp
> BGP table version is 1019, local router ID is 192.168.0.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
> *> 24.48.0.0/14 192.168.0.10 0 3549 7843 i
> *>i24.48.80.0/21 192.168.0.2 0 3549 7843 i
>
> Both of these prefixes have been originated via IGP (the
> "network" command in BGP), as the ORIGIN code on the right indicates.
> The first prefix is learned via an EBGP neighbor, and the second is
> learned via an iBGP neighbor. This is indicated by the status code on
> the left. The absence of an "i" in the status code implies that the
> prefix is learned via an EBGP neighbor.
>
> The BGP selection after MED is to prefer EBGP learned routes
> over iBGP learned routes. However, this selection still has nothing to
> do with administrative distance. Let's suppose that you change the
> distance of iBGP to 1, and EBGP to 254. Assuming that everything is
> equal up to this decision, BGP best path selection will still chose the
> EBGP learned route over the iBGP learned route.
>
> Now lets suppose that you have an iBGP learned prefix, and you
> also have an IGP route to this prefix. Assuming that this iBGP learned
> prefix is best in the BGP table, distance would be the limiting factor
> that would prevent it from making it to the IP routing table.
>
> This is another reason that redistribution of BGP into IGP is
> dangerous. Not only will your IGP not be able to handle the
> redistribution of a full BGP view, any iBGP learned routes will
> automatically be routing through IGP now, since the distances of all
> IGPs are lower than that of iBGP. IOS will try to prevent this by
> default by only letting EBGP learned prefixes be redistributed into IGP,
> however you can change this behavior with the "BGP
> redistribute-internal" command under the BGP process.
>
> My point being, don't confuse administrative distance with the
> BGP best-path selection process. They are completely unrelated.
>
>
> HTH
>
> Brian McGahan, CCIE #8593
> Director of Design and Implementation
> brian@cyscoexpert.com
>
> CyscoExpert Corporation
> Internetwork Consulting & Training
> http://www.cyscoexpert.com
> Voice: 847.674.3392
> Fax: 847.674.2625
>
>
> -----Original Message-----
> From: Omer Ansari [mailto:omer@ansari.com]
> Sent: Wednesday, August 21, 2002 2:42 PM
> To: Brian McGahan
> Cc: 'Ademola Osindero'; 'Yadav, Arvind K (CAP, GECIS)';
> 'VANGADASALAM,SURENDRAN (Non-HP-Singapore,ex4)'; 'Omer Ansari';
> ccielab@groupstudy.com
> Subject: RE: BGP Metric
>
> yes. and just to clarify my (and possibly other ppls) misunderstanding,
> step 5 in the selection process is:
>
> 5.Prefer the path with the lowest origin type: IGP is lower than EGP,
> and EGP is lower than INCOMPLETE.
>
> and not actually the AD , which is more for which route gets into the
> route table.
>
>
> On Wed, 21 Aug 2002, Brian McGahan wrote:
>
> > A side note on MED:
> >
> > http://www.cisco.com/warp/public/459/bgp-med.html
> >
> > And BTW, distance does not have anything to do with BGP best
> > path selection. The BGP decision process is used to determine which
> > path is best. This does not necessarily mean that best routes will
> make
> > it to the IP routing table. Distance is part of this second decision,
> > but not the first.
> >
> > http://www.cisco.com/warp/public/459/25.shtml
> >
> >
> > HTH
> >
> > Brian McGahan, CCIE #8593
> > Director of Design and Implementation
> > brian@cyscoexpert.com
> >
> > CyscoExpert Corporation
> > Internetwork Consulting & Training
> > http://www.cyscoexpert.com
> > Voice: 847.674.3392
> > Fax: 847.674.2625
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > Ademola Osindero
> > Sent: Wednesday, August 21, 2002 7:43 AM
> > To: Yadav, Arvind K (CAP, GECIS); VANGADASALAM,SURENDRAN
> > (Non-HP-Singapore,ex4); 'Omer Ansari'
> > Cc: 'ccielab@groupstudy.com'
> > Subject: RE: BGP Metric
> >
> > Arvind,
> >
> > Omer's explanation is quite right. The issue of admin distance does
> not
> >
> > come into play here . Infact on going thru some old posts, I found
> out
> > that the topic was touched in detail. The key is SYNCHRONIZATION. I
> > either
> > turn off synchronization or ensure the routes are synchronized.
> >
> > I did ensured the routes were fully synchronized and the rule was
> > followed.
> >
> > But this leads me to another question, how do i deal with my DMZ ?
> >
> > Regards,
> > Ademola
> >
> >
> > At 08:18 AM 8/21/2002 -0400, Yadav, Arvind K (CAP, GECIS) wrote:
> > >I think EBGP routes are always prefered over IBGP because of
> > >Administrative Distance, By default med metric is set to 0 to all
> > routers
> > >and router always compare med by default. The
> > >bgp always-compare-med will be usefull when router learns router form
> > two
> > >different ASs.
> > >
> > >Arvind
> > >
> > >-----Original Message-----
> > >From: VANGADASALAM,SURENDRAN (Non-HP-Singapore,ex4)
> > >[mailto:surendran_vangadasalam@non.hp.com]
> > >Sent: Wednesday, August 21, 2002 4:42 PM
> > >To: 'Omer Ansari'; 'Ademola Osindero'
> > >Cc: 'ccielab@groupstudy.com'
> > >Subject: RE: BGP Metric
> > >
> > >
> > >Hi,
> > > I think Omer is somehow right. The bgp always-compare-med
> > should be
> > >used for it to choose the lower med value. If this not done then the
> > >decision process will be skipped to EBGP is better than IBGP.
> > >
> > >Cheers!!
> > >
> > >-----Original Message-----
> > >From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf
> Of
> > >Omer Ansari
> > >Sent: 21 August 2002 09:09
> > >To: Ademola Osindero
> > >Cc: ccielab@groupstudy.com
> > >Subject: Re: BGP Metric
> > >
> > >
> > >I should have explained a little more before shooting my mouth off..
> > >
> > >quoting the great Mr McGahan himself!
> > >
> > >----
> > > As Chris stated, synchronization is the first requirement in
> > the
> > >BGP decision process. After that, the process is as follows:
> > >
> > >Next-hop reachability
> > >Weight
> > >Local Preference
> > >AS-Path (shortest)
> > >Origin Code (EGP > IGP > Unknown)
> > >MED
> > >EBGP over iBGP routes
> > >Shortest internal path
> > >Router-ID (lowest)
> > >
> > > However, there is another criterion that is worth
> mentioning.
> > >Default local-preference for iBGP learned routes on a Cisco router is
> > >100. Although local preference is higher in the decision process
> than
> > >EBGP over IBGP, this is not the default case. You must have a
> > >local-preference greater than the default (100) to choose the iBGP
> > route
> > >over the EBGP route. Therefore if everything (except for the default
> > >local-pref of the iBGP route) is equal for two routes up to the EBGP
> > >over iBGP decision, the EBGP route will be chosen. Even though the
> > iBGP
> > >route has a local-pref of 100, it chooses the EBGP route. Setting
> the
> > >iBGP route to have a local-pref of at least 101 will make it chose
> the
> > >iBGP route first.
> > >----
> > >
> > >hope that helps.
> > >
> > >On Wed, 21 Aug 2002, Omer Ansari wrote:
> > >
> > > > Ademola,
> > > >
> > > > looks like an ebgp route; AD = 20 better than IBGP right?
> > > >
> > > > On Mon, 19 Aug 2002, Ademola Osindero wrote:
> > > >
> > > > > Group,
> > > > >
> > > > > I thought MED is meant to take preference over internal or
> > external
> > >routes
> > > > > but i can't see it happen in the case below. R6 prefers
> > 172.16.20.2 to
> > > > > 192.68.6.1 to reach network 172.16.10.0 despite the fact that
> the
> > latter
> > >as
> > > > > a lower metric of 0.
> > > > >
> > > > > Can anyone explain this?
> > > > >
> > > > > r6#sh ip bgp
> > > > > BGP table version is 7, local router ID is 192.168.11.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
> > > > > *> 172.16.1.0/24 172.16.20.2 100 0 3 i
> > > > > * i 192.68.6.1 50 100 0 3 i
> > > > > *> 172.16.10.0/24 172.16.20.2 100 0 3 i
> > > > > * i 192.68.6.1 0 100 0 3 i
> > > > >
> > > > > r6#sh ip bgp 172.16.10.0
> > > > > BGP routing table entry for 172.16.10.0/24, version 7
> > > > > Paths: (2 available, best #1, table Default-IP-Routing-Table)
> > > > > Advertised to non peer-group peers:
> > > > > 192.68.6.1
> > > > > 3
> > > > > 172.16.20.2 from 172.16.20.2 (172.16.220.1)
> > > > > Origin IGP, metric 100, localpref 100, valid, external,
> > best
> > > > > 3
> > > > > 192.68.6.1 from 192.68.6.1 (192.68.10.2)
> > > > > Origin IGP, metric 0, localpref 100, valid, internal
> > > > >
> > > > >
> > > > > Osindero Ademola
> > > > > Schlumberger Network Solutions
> > > > > Tel: 234 1 261 0446 Ext 5427
> > > > > Fax 234 1 262 1034
> > > > > email:osindero@lagos.sns.slb.com
> > > > >
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:33 GMT-3