From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Thu Apr 29 2004 - 09:00:54 GMT-3
At 12:39 PM +0100 4/29/04, Richard Dumoulin wrote:
>Howard, I was talking in general, not BGP. At school I learnt that
>an engineer is a person who engineers ! This is they are not
>theorists but people who make things work, search for workarounds if
>needed etc ...
Fair enough, as a general term. In some countries, there are
professional codes for certain kinds of engineers. In the USA, this
most frequently applies to civil, structural/mechanical, and other
kinds of engineers who must approve building plans, and must have
passed the Registered Professional Engineer certification.
While the RP certification is not particularly relevant to networking
or software engineering, if I recommended to a customer that they use
synchronization, and their BGP network subsequently failed, they
would have a very good argument for suing me for giving bad advice.
If I represent myself as a BGP expert, it would be pretty easy for a
lawyer to establish I should have known better.
If I had a consulting customer that demanded synchronization, I'd get
it in writing, and also get in writing that I had recommended against
it. As an individual consultant, the liability risk would be too
great to do otherwise. If I was doing it for a consulting company,
I'd document to my management that I recommended against using sync,
and suggest they protect themselves by getting it in writing from the
customer.
I suppose it depends on the local laws and business customs if an
"engineer" is free to recommend things that he or she considers not
to be sound practice. You may know that the "E" in "CCIE" originally
was "engineer", but was changed to "expert' because some US
jurisdictions variously require you be a Registered Professional
Engineer, or at least conform to professional codes, before you can
offer "engineering services."
Yes, I know many companies offer "systems engineering', but that can
become a legal liability.
>
>This is what I was meaning, and I was glad to see Richard Davidson
>provide an "engineering" solution to the absurd task.
>
>You never know when something like this appears.
>
>One day I had a call from a customer who wanted connectivity between
>two of his sites. He already had the routers installed and I was at
>home so I could telnet from my cable modem. I found that the IOS
>that was running on one of the routers was buggy . The customer
>wanted connectivity as soon as possible. I thought I would configure
>an IPSec GRE tunnel with a routing protocol through it, but RIP was
>the only option and GRE was not working. I was happy to find a
>utility to both RIP and IPIP tunnels when I only did configure them
>in lab scenarios before !! Are not RIP and IPIP obsolete ? I think
>so but I am not sure it is official.
RIP version 1 is obsolete. RIP version 2 and IPIP both have
legitimate applications.
RIPv2 can work as the routing protocol for small, simple networks.
Probably even more important is that many servers, primarily UNIX,
listen passively for RIP updates in order to find the default
gateway, rather than getting it through DHCP or IRDP.
IPIP is generally less desirable than GRE because it is less
flexible. It is, however, the digital video over satellite industry
standard. In the IETF, this was part of the work of the
now-concluded Unidirectional Link Routing working group. GRE is an
alternative, but many of the hardware implementations (e.g., set-top
boxes) use IPIP.
At the IETF Oslo meeting a couple of years ago, every satellite
television vendor there said that their firmware used IPIP. While
IPIP is defined in RFC 1853, it is Informational but not Standards
Track. Ironically, it was at that meeting that it was realized that
up to then, GRE was an Informational, not Standards Track, RFC. When
you write a Standards Track RFC, all the protocols to which it refers
must also be standardized, so there was a brief administrative pause
in UDLR until GRE could be reissued as a Proposed Standard.
So, technically, IPIP isn't an IETF standard, but it isn't obsolete.
I think it's fair to say that people will use GRE in new products,
but there still is IPIP in a specialized industry with a very large
number of boxes running it.
>
>Normally employers and customers don't look at details but only at
>results. That is all they want to see in my opinion,
>
>Regards
>
>--Richard
>
>-----Original Message-----
>From: Howard C. Berkowitz [<mailto:hcb@gettcomm.com>mailto:hcb@gettcomm.com]
>Sent: jueves, 29 de abril de 2004 13:18
>To: ccielab@groupstudy.com
>Subject: RE: Another burning question on BGP
>
>
>At 8:31 AM +0100 4/29/04, Richard Dumoulin wrote:
>>Richard, this is what the employers expect from their engineers, being
>>able to find solutions even if the question is absurd. I believe it is
>>also required in the exam. Well done and thank you for making me learn
>>something today,
>>
>>--Richard
>
>At some level of technical seniority, which reasonably is associated
>with the CCIE, it is reasonable to tell an employer when a proposed
>solution is, in fact, absurd, and unlikely to work.
>
>That is a very different case than the artificiality of the lab.
>Also, do consider the very real possibility it is no longer in the
>actual lab, but practice exams do not yet reflect that Cisco stopped
>making it the default, and Cisco ISP workshops tell you not to use it?
>
>Could someone who has recently taken the BGP course update us on
>whether the course recommends using synchronization under any
>circumstances? Even if they mention it, from personal experience as
>an instructor, there have been features that are in the course purely
>because the TAC gets calls on it, even though Cisco design courses
>specifically say not to use them.
>
>Are you saying a real-world employer is going to insist on your using
>synchronization, when Cisco no longer has it as a default, and
>actually discourages its use anywhere except (possibly) the CCIE lab,
>the IETF has declared the function obsolete, and vendors such as
>Juniper never have supported it?
>
>If so, could you help me understand why an employer is sufficiently
>educated in BGP that they even know synchronization exists, but are
>sufficiently clueless about BGP that they demand it be used?
>
> >
>>-----Original Message-----
>>From: Edwards, Andrew M
>>[<mailto:andrew.m.edwards@boeing.com>mailto:andrew.m.edwards@boeing.com]
>>Sent: jueves, 29 de abril de 2004 1:05
>>To: Richard Davidson; Peter van Oene; ccielab@groupstudy.com
>>Subject: RE: Another burning question on BGP
>>
>>
>>Nonetheless, I'm glas I asked and thanks for the response Richard.
>>
>>andy
>>
>>-----Original Message-----
>>From: Richard Davidson
>>[<mailto:rich@myhomemail.net>mailto:rich@myhomemail.net]
>>Sent: Wednesday, April 28, 2004 1:02 PM
>>To: Peter van Oene; ccielab@groupstudy.com
>>Subject: Re: Another burning question on BGP
>>
>>
>>I agree with Peter. However, if my memory serves me
>>this is what to do.
>>
>>At the ASBR (R1) you are redistributing the BGP routes
>>into ospf and they are comming from the ASBR ospf
>>Router ID R1. Those routes get to R3 and they are
>>from ,,, you guessed it R1. Well stop there and
>>switch to BGP.
>>
>>R1 & R3 both peers with R2 which is a RR. When the
>>BGP route gets to R3 it is from R2 "not R1". Sync
>>will fail.
>>Solution: swap BGP router IDs with R2 and R1. Now R1
>>sends a BGP route as if he is R2. R2 gets it and it
>>sends it as if it is R1 to R3. When R3 sees the BGP
>>route is from the R1 BGP Router ID and the OSPF route
>>is from the R1 ospf Router ID it will sync.
>>
>>---------------------
>>{R1}---{R2}----{R3} |
>> |
>> AS1 |
>>---------------------
>>--- Peter van Oene <pvo@usermail.com> wrote:
>>> The short answer is that this is an @#$@'ing
>>> ridiculous scenario that is a
>>> complete waste of your time. If Cisco wants to test
>>> on it, then shame on
>>> them for forcing you to study such a moronic topic.
>>> There is nothing
>>> anywhere near a practical requirement for such a
>>> topology and
>>> synchronization is years more outdated than many of
>>> the already deprecated
>>> items that have found space on the CCIE lab.
> >>
>>>
>>>
>>> At 12:39 PM 4/28/2004, Edwards, Andrew M wrote:
>>> >I'm trying to understand methods to keep
>>> synchronization on in BGP and
>>> >provide BGP to OSPF redistribution with route
>>> reflectors.
>>> >
>>> >You know the problem where the route reflector
>>> server receives an update
>>> >from a route reflector client that is
>>> redistributing BGP to OSPF.
>>> >
>>> >When the route reflector server gets the update, it reflects that
>>> update >to all other RR clients but changes the BGP ID to
>>> itself.
>>> >
>>> >Obviously the other BGP RR clients get the BGP
>>> update but the OSPF
>> > >router ID and BGP ID do not match on the clients so
>>> the BGP route is not
>>> >marked
>>> >As a best path ">"
>>> >
>>> >So the question I have is what methods are
>>> available to make this work
>>> >with synchronization on and using route reflectors?
>>> >
>>> >Is the answer go to full mesh or transfer to confederations?
>>> >
>>> >I'm stumped on how to change the BGP router-id to
>>> the originators BGP
>>> >router ID on the RR server.
>>> >
>>> >Thanks for the input... or clearing up my
>>> confusion.
>>> >
>>> >Andy
>>> >
>>>
>>>______________________________________________________________________
>>>_
>>> >Please help support GroupStudy by purchasing your
>>> study materials from:
>>> ><http://shop.groupstudy.com>http://shop.groupstudy.com
>>> >
>>> >Subscription information may be found at:
>>>
>>>><http://www.groupstudy.com/list/CCIELab.html>http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>_______________________________________________________________________
>>> Please help support GroupStudy by purchasing your
>>> study materials from:
>>> <http://shop.groupstudy.com>http://shop.groupstudy.com
>>>
>>> Subscription information may be found at:
>>>
>>><http://www.groupstudy.com/list/CCIELab.html>http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>=====
>>Richard Davidson
>>Yahoo IM: r1davidson
>>e-mail rich@myhomemail.net
>>
>>_______________________________________________________________________
>>Please help support GroupStudy by purchasing your study materials from:
>><http://shop.groupstudy.com>http://shop.groupstudy.com
>>
>>Subscription information may be found at:
>><http://www.groupstudy.com/list/CCIELab.html>http://www.groupstudy.com/list/CCIELab.html
>>
>>_______________________________________________________________________
>>Please help support GroupStudy by purchasing your study materials from:
>><http://shop.groupstudy.com>http://shop.groupstudy.com
>>
>>Subscription information may be found at:
>><http://www.groupstudy.com/list/CCIELab.html>http://www.groupstudy.com/list/CCIELab.html
>>
>>_______________________________________________________________________
>>Please help support GroupStudy by purchasing your study materials from:
>><http://shop.groupstudy.com>http://shop.groupstudy.com
>>
>>Subscription information may be found at:
>><http://www.groupstudy.com/list/CCIELab.html>http://www.groupstudy.com/list/CCIELab.html
>
>_______________________________________________________________________
>Please help support GroupStudy by purchasing your study materials
>from: <http://shop.groupstudy.com>http://shop.groupstudy.com
>
>Subscription information may be found at:
><http://www.groupstudy.com/list/CCIELab.html>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon May 03 2004 - 19:48:57 GMT-3