From: Scott Morris (swm@emanon.com)
Date: Wed Jun 23 2004 - 17:14:22 GMT-3
Dude, there are plenty of LATA's WITHIN a particular company's structure.
You're thinking grander scale. And you wouldn't order from BellSouth and
Nynex (whatever name du jour), you'd order from your friendly neighborhood
IXC (MCI, Sprint, AT&T, etc.). (Research your PUC archives sometime, you'll
learn interesting tidbits)
But yes, looking at the specifics you mentioned, you're correct... But
since your IXCs have the ability of dropping circuits in the local LATA
areas through resale (dumb copper, no frame interfacing) then that's really
not the problem you're looking at.
Whatever.... I think everyone has gotten the point of why FREEK makes
sense. We can carry our discussion of the good ol' telco arrangements and
legal ramifications thereof offline. :)
Scott
-----Original Message-----
From: Brian Dennis [mailto:bdennis@internetworkexpert.com]
Sent: Wednesday, June 23, 2004 12:41 PM
To: swm@emanon.com; Group Study
Subject: RE: Frame Relay End2 End keepalives
Scott,
When were you able to order a Frame Relay circuit from say BellSouth
between Atlanta and NYC that BellSouth carried end-to-end? A circuit like
this would be BellSouth in Atlanta, WinStar or Sprint out of the local
Atlanta LATA and to the local NYC LATA. And finally a carrier like GTE in
NYC. Of course as a customer you would always call BellSouth if you had
issues with the circuit but they never carried it
end-to-end.
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: Scott Morris [mailto:swm@emanon.com]
Sent: Wednesday, June 23, 2004 9:09 AM
To: Brian Dennis; 'Joe Chang'; 'Group Study'
Subject: RE: Frame Relay End2 End keepalives
"Old days" as in when providers ran their own FR clouds end to end. The
concept of the LATA really had nothing to do with the termination of data
circuits in this fashion. But you're correct in one provider handing off to
another provider. In the voice world, this had to happen at LATA
boundaries, but most of the providers had 'workarounds' to the way that LATA
arrangements worked for data circuits end-to-end at network boundaries.
Even in the mid-90's, most carriers that I had experience with did some
method of re-encapsulation and really only ran TRUE frame-relay at the edges
of their network.
But same diff either way. LMI doesn't get passed correctly, the
"assumption" of up based on reachability occurs, and suddenly you don't know
whether the other end really works or not... Or whether the problem is
within the SP cloud. (Which, of course, never happens!) (problem fixed
while testing!)
:)
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: Brian Dennis [mailto:bdennis@internetworkexpert.com]
Sent: Wednesday, June 23, 2004 12:00 PM
To: Scott Morris; Joe Chang; Group Study
Subject: RE: Frame Relay End2 End keepalives
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