From: Brian McGahan (brian@xxxxxxxxxxxxxxx)
Date: Wed Aug 21 2002 - 21:07:45 GMT-3
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:32 GMT-3