From: Howard C. Berkowitz (hcb@xxxxxxxxxxxx)
Date: Sat Feb 16 2002 - 18:52:24 GMT-3
>Interesting. Since they broke the rule, they just chaged it - nice to be a
>monopoly. They did this before for confedarations:
I don't know if it's a monopoly or just the old boys network (except
there are a number of key women in the BGP world). Paul Traina,
IIRC, originally designed confederations at Cisco, then went to
Juniper, and probably wrote the code to interoperate with his old
code. I don't know if he's one of the Juniper people that moved on
to Procket or Redback.
Same sort of thing for ISIS, where Dave Katz says with some pride
that he has written or extensively modified just about every
implementation running in the network. He started working on what
became GateD, moved to Cisco, then moved to Juniper. Don't know if
the Zebra people wrote their own ISIS. Shantam Biswas did write an
ISIS implementation for a cancelled router at Nortel.
>" 3 AS_CONFED_SET: unordered set of ASs in the local
> confederation that the UPDATE message
> has traversed
>
> 4 AS_CONFED_SEQUENCE: ordered set of ASs in the
> local confederation that the UPDATE
> message has traversed"
>-RFC1965
>
>But Cisco swapped the meaning of 3 and 4 in this. It was a bug, but then,
>majically, it was not
Nah, not really magik....attend an IDR Working Group meeting, and
follow the key people to the bar where these things get worked out.
>"3 AS_CONFED_SEQUENCE: ordered set of Member AS Numbers
> in the local confederation that the UPDATE message has
> traversed
>
> 4 AS_CONFED_SET: unordered set of Member AS Numbers in
> the local confederation that the UPDATE message has
> traversed"
>-RFC3065
>
>
>
>John Neiberger wrote:
>
>> Yep, that's it!
>>
>> Peter posted it a couple of weeks ago but it might have been on
>> the other list. I was feeling too lazy this morning to look it
>> up again.
>>
>> I just checked and this is obsoleted by RFC 3166:
>>
>> 1. Details
>>
>> During a review of internet standards relating to BGP, it
>> became apparent that BGP OSPF interaction, as described in RFC
>> 1403, is not common usage (if at all), and requires significant
>> implementation complexity. Since this mechanism has not been
>> in use in the public internet for many years (if ever), it is
>> proposed to reclassify it to Historic.
>>
>> Thanks,
> > John
>>
>
> >
>> ---- On Tue, 15 Jan 2002, Brian Dennis (brian@5g.net) wrote:
>>
>> > John,
>> > Are you referring to RFC 1403?
>> >
>> > http://www.faqs.org/rfcs/rfc1403.html
>> >
>> > Brian Dennis, CCIE #2210 (R&S)(ISP/Dial) CCSI #98640
>> > 5G Networks, Inc.
>> > brian@5g.net
>> >
>> >
>> >
>> >
>> > From RFC 1403
>> >
>> > 3. BGP Identifier and OSPF router ID
>> >
>> > The BGP identifier MUST be the same as the OSPF router id
>> at all
>> > times that the router is up.
>> >
>> > This characteristic is required for two reasons.
>> >
>> > i Synchronisation between OSPF and BGP
>> >
>> > Consider the scenario in which 3 ASBRs, RT1, RT2,
>> and RT3,
>> > belong to the same autonomous system.
>> >
>> > +-----+
>> > | RT3 |
>> > +-----+
>> > |
>> >
>> > Autonomous System running OSPF
>> >
>> > / \
>> > +-----+ +-----+
>> > | RT1 | | RT2 |
>> > +-----+ +-----+
>> >
>> > Both RT1 and RT2 have routes to an external network
>> X and
>> > import it into the OSPF routing domain. RT3 is
>> advertising
>> > the route to network X to other external BGP
>> speakers. RT3
>> >
>> > must use the OSPF router ID to determine whether it
> > is using
>> > RT1 or RT2 to forward packets to network X and
>> hence build the
>> > correct AS_PATH to advertise to other external
>> speakers.
>> >
>> > More precisely, RT3 must determine which ASBR it is
>> using to
>> > reach network X by matching the OSPF router ID for
>> its route
>> > to network X with the BGP Identifier of one of the
>> ASBRs, and
>> > use the corresponding route for further
>> advertisement to
>> > external BGP peers.
> > >
>> > ii It will be convenient for the network administrator
>> looking at
>> > an ASBR to correlate different BGP and OSPF routes
>> based on
>> > the identifier.
>> >
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On
>> Behalf Of
>> > John Neiberger
>> > Sent: Tuesday, January 15, 2002 7:44 AM
>> > To: j killion; ccielab@groupstudy.com
>> > Subject: Re: RE: BGP "no sync"
>> >
>> >
>> > It's documented in an RFC, but I can't remember which one.
>> > This requirement has been obsoleted by a new RFC but Cisco
>> > hasn't changed the behavior.
>> >
>> > Take the following example:
>> >
>> > [A]---(ospf)-----[B]----(ospf)----[C]
>> > \--------------(ibgp)-------------/
>> >
>> > A and C are iBGP peers. C has an external BGP connection and
>> > it's redistributing eBGP into OSPF. It then advertises those
>> > same routes via iBGP to A.
>> >
>> > A learns these prefixes via OSPF from B and via iBGP from C.
>> > There is your mismatch. If you were to do a 'show ip bgp
>> > a.b.c.d' on one of those routes it would show as not
>> > synchronized even though you'd think it would be.
>> >
>> > You can tweak either the OSPF router ID on B or the BGP
>> router
>> > ID on C. You have to be careful when you do this but it's
>> one
>> > way to fix the problem, depending on your topology.
>> >
>> > HTH,
>> > John
>> >
>> >
> > >
>
> > >
>> > ---- On Tue, 15 Jan 2002, j killion (jkillion1977@yahoo.com)
>> > wrote:
>> >
>> > > I've heard someone else mention the OSPF/BGP router ID
>> > > rule. What does this rule state and is it documented
>> > > somewhere? Must the ID's be the same for it to work
>> > > w/ "no sync"?
>> > > The same formula is used to calculate the OSPF and BGP
>> > > ID, so wouldn't they be the same (unless you started
>> > > one process, added a loopback, then started the
>> > > other)?
>> > >
>> > >
>> > >
>> > >
>> > > --- "Yadav, Arvind K (CAP, GECIS)"
>> > > <Arvind.Yadav@gecis.ge.com> wrote:
>> > > > Pls check , OSPF router ID must match the BGP router
>> > > > ID
>> > > >
>> > > > Arvind
>> > > >
>> > > >
>> > > > -----Original Message-----
>> > > > From: Tony Hanks
>> > > > [mailto:jhconsulting2001@yahoo.com]
>> > > > Sent: Tuesday, January 15, 2002 11:57 AM
>> > > > To: Bob Sinclair; j killion
>> > > > Cc: ccielab@groupstudy.com
>> > > > Subject: RE: BGP "no sync"
>> > > >
>> > > > Bob,
>> > > >
>> > > > I have to disagree. The route in BGP table is not
>> > > > flagged as a "best" route
>> > > > (>). Hence, BGP will not under any circumstances
>> > > > inject it into the routing
>> > > > table.
>> > > >
>> > > > J,
>> > > >
>> > > > The link might explain why the path isn't marked as
>> > > > "not sync".
>> > > >
>> > > > http://www.cisco.com/warp/public/459/25.shtml
>> > > >
>> > > > Tony Hanks
>> > > > MCSE+I, CCNP
>> > > > Network Infrastructure Engineer
>> > > > J & H Consulting Inc.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > -----Original Message-----
>> > > > From: nobody@groupstudy.com
>> > > > [mailto:nobody@groupstudy.com]On Behalf Of
>> > > > Bob Sinclair
>> > > > Sent: Monday, January 14, 2002 6:59 PM
>> > > > To: j killion
>> > > > Cc: ccielab@groupstudy.com
>> > > > Subject: Re: BGP "no sync"
>> > > >
>> > > >
>> > > > It seems to me you have no problem. The BGP table
>> > > > shows 100.1.1.0 to be an
>> > > > ibgp route (admin distance 200). The OSPF route is
>> > > > in the IP table (FIB)
>> > > > because it has a lower admin distance (110). I
>> > > > think you will find that if
>> > > > you remove OSPF, the BGP route will take its place,
>> > > > assuming next hop is
>> > > > reachable. Try: sh ip b 100.1.1.0, and see if all
> > > > > is well with the route.
>> > > >
>> > > > -Bob
>> > > >
>> > > > ----- Original Message -----
>> > > > From: "j killion" <jkillion1977@yahoo.com>
>> > > > To: <ccielab@groupstudy.com>
>> > > > Sent: Monday, January 14, 2002 8:43 PM
>> > > > Subject: BGP "no sync"
>> > > >
>> > > >
>> > > > > I thought I understood the operation of IBGP and
> > > > > the
>> > > > > "no sync" cmd, but now I'm not so sure. Correct
>> > > > me if
>> > > > > I'm wrong, but the two IBGP rules that must be met
>> > > > in
>> > > > > order for an IBGP route to become active is 1) The
>> > > > > router must be able to reach the next hop IP, and
>> > > > 2)
>> > > > > There must be a match for the subnet in the IGP
>> > > > table.
>> > > > > The second rule can be circumvented w/ the use of
>> > > > "no
>> > > > > sync"....Sound good so far? How is this
>> > > > explained?
>> > > > >
>> > > > > bart#sh ip bg
>> > > > > BGP table version is 1, local router ID is
>> > > > 152.1.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
>> > > > > * i100.1.1.0/24 152.1.1.2 0
>> > > > 100
>> > > > > 0 i
>> > > > > bart#ping 152.1.1.2
>> > > > > !!!!!
>> > > > > bart#sh ip rou
>> > > > > 100.0.0.0/24 is subnetted, 1 subnets
>> > > > > O 100.1.1.0 [110/65] via 152.1.1.2, 00:05:53,
>> > > > Serial0
>> > > > >
>> > > > > As you can see, the BGP route isn't active yet I
>> > > > can
>> > > > > ping the next hop IP *and* I have an IGP route for
>> > > > > 100.1.1.0/24. If I add "no sync" the route
>> > > > becomes
>> > > > > active. What am I missing?
>> > > > >
>> > > > > Thanks
>> > > > >
> > > > > >
-- "What Problem are you trying to solve?" ***send Cisco questions to the list, so all can benefit -- not directly to me*** ******************************************************************************* * Howard C. Berkowitz hcb@clark.net Chief Technology Officer, GettLab/Gett Communications Technical Director, CertificationZone.com "retired" Certified Cisco Systems Instructor (CID) #93005
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:25 GMT-3