RE: [SPAM] - RE: [SPAM] - RE: Other ways of solving it ---

From: Guyler, Rik (rguyler@shp-dayton.org)
Date: Tue Dec 27 2005 - 16:49:03 GMT-3


Gustavo, just because a solution is "easy" doesn't make it wrong. If your
initial idea on how to do this fits the requirements then go with it.
Personally, I like the idea of manipulating OSPF to not prefer the PPP link
since this gives you link failure at Layer 2, which is required. Be careful
of making something harder than it is.

Rik

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Gustavo Novais
Sent: Tuesday, December 27, 2005 2:02 PM
To: Christian Sica; Chula Bandara; Cisco certification
Subject: RE: [SPAM] - RE: [SPAM] - RE: Other ways of solving it ---
frame-relay backup - Sending mail server found on dnsbl.njabl.org - Sending
mail server found on relays.ordb.org

The wording of the section 2.2 says that I must not use dynamic mappings AND
not use static mapping BETWEEN the spokes. That is because later on OSPF
section you have to configure ospf point-to-multipoint network on the
interfaces, which will generate a /32 to the hub. Then by routing you are
able to reach the other spoke.

If this was an ISDN environment I would not hesitate about configuring
dialer-watch to backup this. But it isn't.

Are you suggesting some kind of tracking of the /32 route injected by ospf
p2mp in order to trigger the backup?

Is that possible on a dedicated-line-backup-environment?

Gustavo Novais

-----Original Message-----
From: Christian Sica [mailto:csica@liweb.net]
Sent: terga-feira, 27 de Dezembro de 2005 18:53
To: Gustavo Novais; 'Chula Bandara'; 'Cisco certification '
Subject: [SPAM] - RE: [SPAM] - RE: Other ways of solving it --- frame-relay
backup - Sending mail server found on dnsbl.njabl.org - Sending mail server
found on relays.ordb.org

Gustavo,

True, the backup feature will not detect a pvc failure. It will only go
down if it stops receiving LMI from the local frame switch. So there must
be another way, and there is. I would recommend going back and looking at
your config for section 2.2. Your config is using physical interfaces, so
that means sub interfaces are out of the question. However, you are also
not allowed to use either dynamic or static mapping. So, the question is,
how did you configure your frame connection here to meet these requirements?

Thanks,
Christian

-----Original Message-----
From: Gustavo Novais [mailto:gustavo.novais@novabase.pt]
Sent: Tuesday, December 27, 2005 1:34 PM
To: Christian Sica; Chula Bandara; Cisco certification
Subject: RE: [SPAM] - RE: Other ways of solving it --- frame-relay backup -
Sending mail server found on dnsbl.njabl.org

Hi,
I see your point, but the backup feature only allows me to backup an
interface that is physically down. As we know, the fact of one PVC going
down on a major interface does not trigger the backup interface up.

I still have not cleared completely out this issue, and that is why I've
sent this mail to the group. This was based on IEWB v3.0 lab 19. If any of
the authors wish to pronunciate...

Thank you

Gustavo Novais

-----Original Message-----
From: Christian Sica [mailto:csica@liweb.net]
Sent: terga-feira, 27 de Dezembro de 2005 18:01
To: Gustavo Novais; 'Chula Bandara'; 'Cisco certification '
Subject: [SPAM] - RE: Other ways of solving it --- frame-relay backup -
Sending mail server found on dnsbl.njabl.org

I don't see how using the "ip ospf demand-circuit" feature will help you
here. This command was designed to allow an OSPF adjacency to remain up
without sending constant hello packets out the interface. This was usefull
for ISDN since it would allow the neighborship to form over the ISDN link
without keeping the ISDN circuit up. I would suggest you look at the
"backup" feature. Look at the wording, "Configure the network in such a way
that this link is only used if R4 (a spoke) loses its connection to the
frame-relay cloud." So, if you just set the cost of the PPP link to say
1000, does that meet the requirements? Is that enough to prevent any
traffic from using the circuit unless the frame circuit is down? Try it
out.

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Gustavo Novais
Sent: Tuesday, December 27, 2005 9:54 AM
To: Chula Bandara; Cisco certification
Subject: RE: Other ways of solving it --- frame-relay backup

Yes,

I think that both of them (increasing cost and demand-circuit) must be used.
Increase cost because we do not wish the circuit to be used, and Demand
Circuit to suppress hellos, and then effectively we do NOT use the ppp link.

I think that either of those used by its own would not guarantee that you
would not use the ppp link (unless FR goes down on R4)

Gustavo Novais

________________________________

From: Chula Bandara [mailto:chula_bandara@hotmail.com]
Sent: terga-feira, 27 de Dezembro de 2005 14:48
To: Gustavo Novais
Subject: RE: Other ways of solving it --- frame-relay backup

I think , you can also do a ip ospf demand-circuit over a point-to-point
circuit.

________________________________

        From: "Gustavo Novais" <gustavo.novais@novabase.pt>
        Reply-To: "Gustavo Novais" <gustavo.novais@novabase.pt>
        To: "Cisco certification " <ccielab@groupstudy.com>
        Subject: Other ways of solving it --- frame-relay backup
        Date: Tue, 27 Dec 2005 14:27:18 -0000
        Hello group,

        I have a task where I'm asked to do a backup of a frame-relay
circuit
        using OSPF. The backup line is a dedicated serial line encapsulated
with
        ppp. The wording is as follow:

        Configure area 0 on the ppp link between R4 and R5

        The ppp link will be a backup of of frame-relay connection between
R4
        and R5 (both using major interfaces, R5 hub, R4 spoke). Configure
the
        network in such a way that this link is only used if R4 (a spoke)
loses
        its connection to the frame-relay cloud.

        My obvious solution to this is just to increase the ospf cost of the
        interfaces involved on the ppp link, in order that it does not show
up
        as the preferred path between R4 and R5.

        My doubt is that perhaps this solution may be too obvious, and
perhaps I
        am missing something...

        Any suggestions or alternative ways of doing this? Am I just being
        paranoid about complexity?

        Thank you

        Gustavo Novais

        



This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:52 GMT-3