Dear Marko,
Kindly check the below output in order to illustrate what is mean.
The following output is on the ASBR (which is also the RR) for the first AS.
R2#sh ip bgp vpnv4 all 123.123.123.123
BGP routing table entry for 1000:2:123.123.123.123/32, version 11
Paths: (2 available, best #2, table sp1000)
Flag: 0x820
Advertised to update-groups:
2 3
1000, (Received from a RR-client), imported path from 1000:3:
123.123.123.123/32
200.254.254.3 (metric 10) from 200.254.254.3 (200.254.254.3)
Origin IGP, metric 0, localpref 100, valid, internal
Extended Community: RT:1000:1000,
mpls labels in/out 214/306
1000
20.0.100.2 from 20.0.100.2 (123.123.123.123)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: 200:2
Extended Community: RT:1000:1000,
mpls labels in/out 214/imp-null
BGP routing table entry for 1000:3:123.123.123.123/32, version 9
Paths: (1 available, best #1, no table)
Flag: 0x820
Advertised to update-groups:
2 3
1000, (Received from a RR-client)
200.254.254.3 (metric 10) from 200.254.254.3 (200.254.254.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1000:1000,
mpls labels in/out nolabel/306
This output if from the RR of the second AS
BGP routing table entry for 1000:2:123.123.123.123/32, version 29
Paths: (1 available, best #1, no table)
Flag: 0x800
Advertised to update-groups:
2
200 1000
200.254.254.2 (metric 1) from 200.254.254.2 (200.254.254.2)
Origin IGP, localpref 100, valid, external, best
Community: 200:2
Extended Community: RT:1000:1000,
mpls labels in/out nolabel/214
BGP routing table entry for 1000:3:123.123.123.123/32, version 3
Paths: (1 available, best #1, no table)
Advertised to update-groups:
2
200 1000
200.254.254.3 (metric 1) from 200.254.254.2 (200.254.254.2)
Origin IGP, localpref 100, valid, external, best
Extended Community: RT:1000:1000,
mpls labels in/out nolabel/306
This is the output from the PE inside the second AS.
R8#sh ip bgp vpnv4 all 123.123.123.123
BGP routing table entry for 1000:2:123.123.123.123/32, version 8
Paths: (1 available, best #1, no table)
Not advertised to any peer
200 1000
200.254.254.2 (metric 1) from 100.254.254.9 (100.254.254.9)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1000:1000,
mpls labels in/out nolabel/214
BGP routing table entry for 1000:3:123.123.123.123/32, version 5
Paths: (1 available, best #1, no table)
Not advertised to any peer
200 1000
200.254.254.3 (metric 1) from 100.254.254.9 (100.254.254.9)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1000:1000,
mpls labels in/out nolabel/306
BGP routing table entry for 1000:8:123.123.123.123/32, version 9
Paths: (2 available, best #1, table sp1000)
Advertised to update-groups:
1
200 1000, imported path from 1000:3:123.123.123.123/32
200.254.254.3 (metric 1) from 100.254.254.9 (100.254.254.9)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1000:1000,
mpls labels in/out 816/306
200 1000, imported path from 1000:2:123.123.123.123/32
200.254.254.2 (metric 1) from 100.254.254.9 (100.254.254.9)
Origin IGP, metric 0, localpref 100, valid, internal
Extended Community: RT:1000:1000,
mpls labels in/out 816/214
As you can see R8 choose 200.254.254.3 as the best path and this is the root
of my question why this is happening.
Kindly if you need any thing else let me know.
Thanks a lot
On Sun, Oct 18, 2009 at 12:44 PM, Marko Milivojevic <[email protected]>wrote:
> If they are all internal, all routes will be advertised if they have
> different RD. However, the topology you posted has ASBRs - routes
> advertised between them are external, not internal... Or am I missing
> out on something in your description of the problem?
>
> Can you post some more information - configurations, "show" output, etc.
>
> --
> Marko
> CCIE #18427 (SP)
> My network blog: http://cisco.markom.info/
>
> On Sun, Oct 18, 2009 at 10:41, karim okasha <[email protected]> wrote:
> > Dear Marko,
> >
> > Thanks a lot for your support but the rule that you mention apply only
> for
> > external prefix and from the topology that i mentioned both routes that
> are
> > received by the PE are internal routes also as i mentioned i tried
> flapping
> > the best route and it is always chosen so the oldest is better doesn't
> apply
> > here.
> >
> > I hope you get my point and if you think there is something wrong with
> what
> > is said kindly illustrate.
> >
> > Thanks a lot
> >
> > On Sun, Oct 18, 2009 at 11:48 AM, Marko Milivojevic <[email protected]>
> > wrote:
> >>
> >> Hello Karim. You may have misunderstood the tie break process just a
> >> little bit. Nothing to blame you for, this is an obscure case.
> >> Usually, tie break will happen on RR, as ti will advertise only the
> >> best prefix and not all it has. On initial RR, not all parameters are
> >> the same, so it can make a decision...
> >>
> >> ...the exception is if the same prefix is in VPNv4 with different RD.
> >> In this case, indeed, RR will advertise the "same" prefix to its
> >> neighbors. RD can't be used as tie breaker, as it separates the
> >> prefixes. Indeed, this is the situation that you may be having. So,
> >> decision is left where it is now and where not all information is
> >> useful or available.
> >>
> >> In this case, very unusual tie break rule will be used - prefix that
> >> was received first, stays. See here (step 10):
> >>
> >>
> >>
> http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml
> >>
> >> Just remember that nothing in BGP is random :-).
> >>
> >> --
> >> Marko
> >> CCIE #18427 (SP)
> >> My network blog: http://cisco.markom.info/
> >>
> >> On Sun, Oct 18, 2009 at 04:15, karim okasha <[email protected]> wrote:
> >> > Dear Bryan,
> >> >
> >> > Thanks a lot for your support. But i wanted to know exactly on what
> >> > basis
> >> > would the router choose one path over the other and let me explain.
> >> >
> >> > If the 2 paths are completely equal in every thing the last three
> >> > tiebrakers
> >> > will be as follows.
> >> >
> >> > 1- Prefer the path from the lowest BGP router ID
> >> > (The Router ID is the same as the route came from a RR so both
> >> > routes
> >> > have the same originator)
> >> >
> >> > 2- prefer the path with the minimum cluster length.
> >> > (again the 2 paths have the same cluster length)
> >> >
> >> > 3- Prefer the path with the lowest neighbor address.
> >> > (I think that both will have the same value as the 2 routes again
> >> > are
> >> > originated from the same Router which is the RR).
> >> >
> >> > That's is why i wanted to know what is the exact criteria to prefer
> one
> >> > route over the other as in this specific example in the WB i tried
> >> > flapping
> >> > the session between the CE and R3 but every time once the session go
> up
> >> > the
> >> > router is the other AS starts prefering the route from R3 again.
> >> >
> >> > Again thanks a lot for your help.
> >> >
> >> > On Sat, Oct 17, 2009 at 11:42 PM, Bryan Bartik <[email protected]>
> >> > wrote:
> >> >>
> >> >> Karim,
> >> >>
> >> >> The path selection process is the same. Not sure what the tie-breaker
> >> >> is
> >> >> in this case but it looks like it's pretty far down the list...
> >> >>
> >> >> On Fri, Oct 16, 2009 at 11:13 AM, karim okasha <[email protected]>
> >> >> wrote:
> >> >>>
> >> >>> Dear all,
> >> >>>
> >> >>> I have a problem with task 7.4 in this Lab. this task states that we
> >> >>> need
> >> >>> to configure R9 so that traffic from R8 always favors R2.
> >> >>>
> >> >>> The solution is understood but my problem is why in the first place
> >> >>> does
> >> >>> R8 favors the route coming from R3 instead of the Router coming from
> >> >>> R2.
> >> >>>
> >> >>> I need to understand how BGP selects the best route in the following
> >> >>> situation.
> >> >>>
> >> >>> ---- PE1
> >> >>> CE1 -- ---- ASBR ---- ASBR --- PE3
> >> >>> --- PE2 (RR) (RR)
> >> >>>
> >> >>> How is PE3 going to choose the best path towards CE1.
> >> >>>
> >> >>> Your help is very much appreciated.
> >> >>>
> >> >>>
> >> >>> _______________________________________________
> >> >>> For more information regarding industry leading CCIE Lab training,
> >> >>> please
> >> >>> visit www.ipexpert.com
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Bryan Bartik
> >> >> CCIE #23707 (R&S), CCNP
> >> >> Sr. Support Engineer - IPexpert, Inc.
> >> >> URL: http://www.IPexpert.com
> >> >
> >> >
> >> > _______________________________________________
> >> > For more information regarding industry leading CCIE Lab training,
> >> > please
> >> > visit www.ipexpert.com
> >> >
> >> >
> >
> >
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit
www.ipexpert.com
