From: Scott Morris (swm@emanon.com)
Date: Wed Jun 23 2004 - 10:32:45 GMT-3
In the "old" days of pure frame relay networks, things worked well and you
never needed to worry about inaccurate information from LMI (not much
anyway).
However, today's networks are compeltely different. Many service providers
will re-encapsulate the frame relay into IP or MPLS or whatever else they
feel like within their own networks. This re-encapsulation essentially
nullifies the reliabilty of LMI for end-to-end reachability usage. Of
course, as long as a "route" exists to the other end of the SP network, it
will "appear" as being reachable (active) but that may not be accurate.
So in came end-to-end keepalives, where the customer could essentially
monitor their own PVCs to attain true reachability information to keep the
network as accurate as possible!
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP,
JNCIP, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Joe
Chang
Sent: Wednesday, June 23, 2004 9:06 AM
To: Group Study
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
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:48 GMT-3