From: Brian Dennis (bdennis@internetworkexpert.com)
Date: Wed Jun 23 2004 - 13:00:16 GMT-3
Scott,
Define "old days" as it has been a problem for years ;-) I
remember as far back as the mid-90s running into issues related to one
side of a Frame Relay connection being down hard and the other being
up/up. The problem is normally experienced with long haul Frame Relay
circuits that are not carried by the same Frame Relay provider from
end-to-end. This was quite common with the regulations restricting the
RBOCs (telcos) from being able to transport data between the different
LATAs. When one Frame Relay provider (i.e. Pac Bell) would hand off the
DLCI to another provider (i.e. WinStar) in order to transport it across
a LATA boundary, the Frame Relay providers would commonly not inform
each other of the DLCI status at the NNI. This of course meant that the
DLCI status represented the status of the DLCI between the local router
and the NNI and not between the local router and the remote router.
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Scott Morris
Sent: Wednesday, June 23, 2004 6:33 AM
To: 'Joe Chang'; 'Group Study'
Subject: RE: Frame Relay End2 End keepalives
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
>
>
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:49 GMT-3