From: ccie2be (ccie2be@nyc.rr.com)
Date: Wed Jun 23 2004 - 10:52:50 GMT-3
Hi Joe,
When there are multiple frame switches in the path of a pvc ( or maybe svc
also), the frame switches don't always inform each other of the status of
their locally connected dlci's.
This can lead to a situation where a router is being told by it's first hop
frame switch that everything's OK, when, in fact, somewhere along the path
of the pvc beyond the first hop frame switch there's a problem. Now, if the
PVC is configured with backup interface BRI0 and the status of the interface
is up/up (because the frame switch says all is OK), the backup won't kick
in.
By using FREEK, the backup will kick in if there's a problem anywhere along
the pvc path because now the routers have a way of determining the status of
the pvc end-to-end that's independent of the status info provided by the f/r
lmi messages.
Hope that explanation clears that up.
----- Original Message -----
From: "Joe Chang" <changjoe@earthlink.net>
To: "Group Study" <ccielab@groupstudy.com>
Sent: Wednesday, June 23, 2004 9:06 AM
Subject: Re: Frame Relay End2 End keepalives
> Why is there a need for a feature like FREEK? Is NNI that unreliable, or
is
> NNI not the only way to link FR switches?
>
> ----- Original Message -----
> From: "Geert Nijs" <geert.nijs@simac.be>
> To: "ccie2be" <ccie2be@nyc.rr.com>; "Kenneth Wygand"
> <KWygand@customonline.com>; "Group Study" <ccielab@groupstudy.com>
> Sent: Tuesday, June 22, 2004 5:39 PM
> Subject: RE: Frame Relay End2 End keepalives
>
>
> > The trick is applying a frame-relay class map ONLY to ONE DLCI in a P2MP
> > interface.
> > This is done as follows:
> >
> > interface Serial0.2 multipoint
> > ip address 150.50.100.2 255.255.255.224
> > frame-relay map ip 150.50.100.2 205
> > frame-relay map ip 150.50.100.5 205 broadcast
> > frame-relay map ip 150.50.100.6 206 broadcast
> > frame-relay interface-dlci 205
> > class END2END
> >
> > map-class frame-relay END2END
> > frame-relay end-to-end keepalive mode bidirectional (or whatever you
> > want)
> >
> >
> > This has nothing to do with "dynamic" DLCI's. That implies that you
> > simply disable inverse-arp.
> >
> > Regards,
> > Geert
> >
> > -----Oorspronkelijk bericht-----
> > Van: nobody@groupstudy.com [mailto:nobody@groupstudy.com] Namens ccie2be
> > Verzonden: dinsdag 22 juni 2004 23:18
> > Aan: Kenneth Wygand; Group Study
> > Onderwerp: Re: Frame Relay End2 End keepalives
> >
> >
> > Hmmm. That's a very interesting idea.
> >
> > I didn't think one could use both f/r static maps and the f/r
> > interface-dlci command together under the same interface. Have you ever
> > tried that? I haven't.
> >
> > But,....
> >
> > I'm not sure about that dynamic mapping prohibition. I just figured if
> > dynamic mapping is allowed, then you can't use the interface-dlci
> > command. Period.
> >
> > What I don't understand is why isn't there a class option in the fram
> > map ip command? Heck, there are lot's of other options. Why not this
> > one?
> >
> > In fact, isn't class an option with the dialer map command?
> >
> > Tim
> > ----- Original Message -----
> > From: "Kenneth Wygand" <KWygand@customonline.com>
> > To: "ccie2be" <ccie2be@nyc.rr.com>; "Group Study"
> > <ccielab@groupstudy.com>
> > Sent: Tuesday, June 22, 2004 4:59 PM
> > Subject: RE: Frame Relay End2 End keepalives
> >
> >
> > Tim,
> >
> > I believe, even though you are using frame maps, you should still put
> > this configuration on the DLCI through "frame-relay interface-dlci xxx"
> > and putting it under that configuration mode. I don't think this
> > implies that you are using dynamic DLCI assignments.
> >
> > Hopefully someone will correct me if I am wrong.
> >
> > Kenneth E. Wygand
> > Systems Engineer, Project Services
> > CISSP #37102, CCNP, CCDP, ACSP, Cisco IPT Design Specialist, MCP, CNA,
> > Network+, A+
> > Custom Computer Specialists, Inc.
> > "The only unattainable goal is the one not attempted." -Anonymous
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> > ccie2be
> > Sent: Tuesday, June 22, 2004 4:45 PM
> > To: Group Study
> > Subject: Frame Relay End2 End keepalives
> >
> > Hey guys,
> >
> > Got another network puzzle.
> >
> > R4 is the hub of a spoke and hub FR cloud connecting R5 and R3.
> >
> > All config's are on multipoint interfaces.
> >
> > There's also an isdn circuit between R4 and R5.
> >
> > This task forbids me to use any dynamic mappings or dlci's that weren't
> > specified.
> >
> > I'm to config FR end2end keepalives (FREEK) in order to detect if R5's
> > F/R connection to R4 is actually down.
> >
> > R5 is to poll R4 and R4 is supposed to respond.
> >
> > I configured everything as stated and it seemed to work - at least for a
> > while. But, periodically, I would lose connectivity.
> >
> > Since FREEK has to be configured in a map-class, I wanted to assign the
> > map-class to the particular dlci's relevant to this task.
> >
> > But, as it turns out, unless I'm mistaken, there's no class option
> > available in the fram map ip statement. So, instead, I just assigned the
> > map-class to the interface or multipoint subinterface.
> >
> > BTW, the idea was that if the f/r link between R4 and R5 went down, this
> > would trigger R5 to call R4 over the isdn circuit.
> >
> > After struggling with this for a while, I simply had to turn off FREEK
> > cause it was messing up ospf and the other IGP's running in the network.
> >
> > Anyone know how I should have solved this problem? Or, more
> > specifically, how should FREEK be configured on a multipoint interface?
> > I've only seen it configured on p2p interfaces.
> >
> > All ideas are greatly welcomed.
> >
> > Thanks, Tim
> >
> > _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials from:
> > http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials from:
> > http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
>
############################################################################
> #########
> > This e-mail and any attached files are confidential and may be legally
> privileged.
> > If you are not the addressee, any disclosure, reproduction, copying,
> distribution,
> > or other dissemination or use of this communication is strictly
> prohibited.
> > If you have received this transmission in error please notify Simac
> immediately
> > and then delete this e-mail.
> >
> > Simac has taken all reasonable precautions to avoid virusses in this
> email.
> > Simac does not accept liability for damage by virusses, for the correct
> and complete
> > transmission of the information, nor for any delay or interruption of
the
> transmission,
> > nor for damages arising from the use of or reliance on the information.
> >
> > All e-mail messages addressed to, received or sent by Simac or Simac
> employees
> > are deemed to be professional in nature. Accordingly, the sender or
> recipient of
> > these messages agrees that they may be read by other Simac employees
than
> the official
> > recipient or sender in order to ensure the continuity of work-related
> activities
> > and allow supervision thereof.
> >
>
############################################################################
> #########
> >
> > _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials from:
> > http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:48 GMT-3