From: StudyManiac (groupstudy1@xxxxxxxx)
Date: Tue Feb 05 2002 - 00:24:57 GMT-3
Can anyone tell me what significance the RID for BGP and OSPF have in this
problem? Did I miss out on some new feature, or is it that there really is
no relationship between these router IDs?
JOE
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Peter van Oene
Sent: Monday, January 21, 2002 9:20 AM
To: DOLLING,ERNESTO (HP-Argentina,ex1); 'Adam Quiggle '; 'Andy XueWen
Qin '; 'ccielab@groupstudy.com '
Subject: RE: BGP Synchronization and OSPF IGP
Couple things. First off, I'm not sure if Cisco will match against the
originator_id first if it exists, and router_id second. This would solve
this issue. However, keep in mind that synch is OBSOLETE. Further, when
we used synch (rarely) it was likely in pre RR topologies. For example,
you wouldn't need RR's if you didn't fully mesh your IBGP which is why you
would need synch in the first place. So again, designing, or modifying the
protocol implementation to suit the below setup is moot. In other words,
it would be a complete waste of time.
From here stems my disdain for cisco forcing folks to study this arcane
crap. Why not focus on real life topics?
Pete
At 07:43 AM 1/20/2002 -0500, DOLLING,ERNESTO (HP-Argentina,ex1) wrote:
>People,
>
>I totally agree that a route inyected into OSPF (typically E2 type) would
>have a router-id origin of the ASBR who did the job, and will not change in
>the entire OSPF domain.
>So far, so good, but what about the router-id of the BGP peer advertising
>the prefix???
>
>In a fully mesh iBGP environmet no problems will occur, since every BGP
>speaker will obtain the prefix from the same ASBR router, and the only
>concern is to be sure "BGP router id" and "ospf router id" match in the
>ASBR.
>
>But what about not iBGP fully meshed peers (like route-reflector
>environments??) Here a problem could arise. Let's supouse the ASBR is a
>spoke (route-reflector client) in the route-reflector cloud. Other
>route-reflector clients will receive the prefix trough the
>"route-reflector", and will not sync, since OSPF has the "router-id" from
>the ASBR.
>
>Please let me know if I4m wrong here.
>
>Ernesto.
>
>
>-----Original Message-----
>From: Adam Quiggle
>To: Peter van Oene; Andy XueWen Qin; ccielab@groupstudy.com
>Sent: 1/20/02 1:28 AM
>Subject: Re: BGP Synchronization and OSPF IGP
>
>Peter,
>
>Because not all the routers in your AS are running BGP and you are
>a transit AS.
>
>AQ
>
>At 11:23 PM 1/19/02, Peter van Oene wrote:
> >Hey Adam,
> >
> >Why would you learn routes via EBGP that already exist in your IGP?
> >
> >At 01:57 PM 1/19/2002 -0500, Adam Quiggle wrote:
> >>Andy,
> >>
> >>I believe you are right and that my analysis is flawed. What if
> >>the scenario were:
> >>
> >>R1---(eBGP)---R2---(Area0)---R3---(Area1)---R4
> >>
> >>and R4 were the source for the BGP route and an internal OSPF
> >>route then I think that situation described below would apply.
> >>Do you agree?
> >>
> >>AQ
> >>
> >>At 01:49 PM 1/19/02, Andy XueWen Qin wrote:
> >>>See my comments in line.
> >>>
> >>>Thanks
> >>>Andy
> >>>
> >>>On Sat, 19 Jan 2002, Adam Quiggle wrote:
> >>>
> >>> > Date: Sat, 19 Jan 2002 11:32:17 -0500
> >>> > From: Adam Quiggle <aquiggle@nc.rr.com>
> >>> > To: ccielab@groupstudy.com
> >>> > Subject: BGP Synchronization and OSPF IGP
> >>> >
> >>> > Ok gang, thanks to the postings of EA Louie on this subject and
> >>> > some lab work I believe that I have an understanding of how to
> >>> > make this work and the gotchas. Let me see if I can summarize,
> >>> > and as always if I'm wrong...somebody let me know. :-)
> >>> >
> >>> > Scenario:
> >>> >
> >>> > R1---(eBGP)---R2---(Area0)---R3---(Area1)---R4---(eBGP)---R5
> >>> >
> >>> > BGP
> >>> > -----------------
> >>> > AS1 - R1 (RID - 1.1.1.1)
> >>> > AS2 - R2 (RID - 2.2.2.2)
> >>> > AS2 - R3 (RID - 3.3.3.3)
> >>> > AS2 - R4 (RID - 4.4.4.4)
> >>> > AS3 - R5 (RID - 5.5.5.5)
> >>> >
> >>> > OSPF
> >>> > -----------------
> >>> > R2 is an ABR and ASBR (RID 2.2.2.2)
> >>> > R3 is an ABR and (RID 3.3.3.3)
> >>> > R4 is an ASBR (RID 4.4.4.4)
> >>> >
> >>> > Stipulation: Inject BGP routes learned from R5 into OSPF and
> >>> > dynamically propagate them to R1. You can't use "no sync" on
> >>> > R2.
> >>> >
> >>> > Problem: Because you must use synchronization on R2 the BGP RID
> >>> > and OSPF RID must match before a route will get advertised to R1.
> >>> > However, because R2 and R4 are in different OSPF areas, R2 will
> >>> > never see a route sourced from R4, it will always see the routes
> >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>> Are you sure ? If you redistribute the external
> >>> routes on R4 into OSPF, it'll always show up as
> >>> originated from R4 in the whole OSPF domain.
> >>> R3 is just playing a role of passing LSAs, it won't
> >>> change the route's originator to himself.
> >>> I tested it, the BGP/OSPF ID confliction won't be
> >>> a problem in your scenario.
> >>>-----------------------------------
> >>> > being sourced from R3. Thus, even if the BGP routerid and OSPF
> >>> > routerid on R4 are identical, the routes will never get sent to
>R1.
> >>> >
> >>> > Solution: Change the OSPF RID on R3 to 4.4.4.4 and OSPF RID on R4
> >>> > to something else such as 9.9.9.9 (so that you don't get
>conflicting
> >>> > OSPF RIDs). Now R2 will see the BGP RID of a route from R4 as
>4.4.4.4
> >>> > and learn the OSPF route from RID 4.4.4.4 and the route will get
> >>> > sync'd and subsequently sent to R1.
> >>> >
> >>> > Now, I know this works, but I'm not sure if the rationale is
>right.
> >>> > Subsequently I must now ask what about the other various IGPs that
> >>> > could be used. Seeing how RIDs don't play a big part in RIP, IGRP
> >>> > and EIGRP I don't see the same "gotcha" from these IGPs.
> >>> >
> >>> > Comments?
> >>> >
> >>> > Thanks,
> >>> > AQ
> >>> > **Note: CCIE Security list is available. For more information go
>to:
> >>> > http://www.groupstudy.com/list/security.html
> >>**Note: CCIE Security list is available. For more information go to:
> >>http://www.groupstudy.com/list/security.html
> >**Note: CCIE Security list is available. For more information go to:
> >http://www.groupstudy.com/list/security.html
>**Note: CCIE Security list is available. For more information go to:
>http://www.groupstudy.com/list/security.html
**Note: CCIE Security list is available. For more information go to:
http://www.groupstudy.com/list/security.html
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:11 GMT-3