From: Christian Sica (csica@liweb.net)
Date: Tue Dec 27 2005 - 19:03:43 GMT-3
Alright, now your getting a little too technical :) Your right, with
flood-reduction, your still sending hello's. But the hello's are for
keeping the adjacency up and notifying the neigborship if there are any
changes. Without the hello's, you could remove OSPF from R4 and R5 would
still keep its neighborship up. But either way, your going to send traffic
over the ppp link, even if its just to initially setup the neighborship.
That is why I was leaning towards using the backup command for this, but
maybe im over engineering this. Definity a question for the proctor though.
-----Original Message-----
From: Gustavo Novais [mailto:gustavo.novais@novabase.pt]
Sent: Tuesday, December 27, 2005 4:37 PM
To: Christian Sica; Chula Bandara; Cisco certification
Subject: RE: [SPAM] - RE: [SPAM] - 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 - Sending
mail server found on relays.ordb.org - Sendi
The ospf flood reduction feature suits you when you want to reduce flooding
of the LSAs of OSPF. Instead of flooding them every 30 min, you set them
with a DNA bit, and you do not flood them.
You do not suppress hellos with this feature (do a deb ip ospf hello to
see). Hence you are still using the link :)
Gustavo Novais
-----Original Message-----
From: Christian Sica [mailto:csica@liweb.net]
Sent: terga-feira, 27 de Dezembro de 2005 21:27
To: Gustavo Novais; 'Chula Bandara'; 'Cisco certification '
Subject: [SPAM] - RE: [SPAM] - 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 - Sending
mail server found on relays.ordb.org - Sending m
I guess you could look at this two ways. First, if they are looking for you
to use the backup interface command to take the ppp link down when the frame
is up, you could accomplish this with a tunnel interface and use the backup
command on it. When properly configured the tunnel will go down if R5 loses
its frame connection to R4, thus triggering the backup ppp link and
restoring connectivity.
The other way to look at it is to configure OSPF to use the frame as primary
and limit as much traffic over the ppp link unless the frame connection is
down. As you mentioned, we can accomplish this using cost. The demand
circuit may help by limiting hello's, but you may want to look into using
the ospf flood-reduction command instead. It is better suited for dedicated
links. Here is more info:
http://www.cisco.com/warp/public/104/dc.html
Perhaps when Brian D. or Briam M. return from their holiday they can shed a
little light on this and what they had in mind for a solution. I would be
very interested on what the intended solution is.
Regards,
Christian
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Gustavo Novais
Sent: Tuesday, December 27, 2005 3:25 PM
To: Christian Sica; Chula Bandara; Cisco certification
Subject: RE: [SPAM] - 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 - Sending mail server found on
relays.ordb.org
Hi
What I thought of was just to increase ospf cost on the ppp link, so that it
is not used by "regular" traffic. Besides that, we must not forget that
although the cost is high, the OSPF hello packets are still flowing through
it. So, suppress them. To do that - ip ospf demand-circuit.
Does that mean that if I ping R5 side of the link from R4 it will not use
the directly connected route? No. But I this is the best I can figure out
given the restrictions.
I'd just wish that the IEWB solutions guide were out before my exam, to
clear that kind of doubts... but I guess I won't be so lucky.
Gustavo Novais
-----Original Message-----
From: Christian Sica [mailto:csica@liweb.net]
Sent: terga-feira, 27 de Dezembro de 2005 20:15
To: Gustavo Novais; 'Chula Bandara'; 'Cisco certification '
Subject: [SPAM] - 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 - Sending mail server found on
relays.ordb.org
Gustavo,
Ok, this one got me to thinking so I lab'd it up. Your right, the frame
mapping restriction is only from spoke to spoke, and as you stated OSPF PtMP
fixes that. I don't think that dialer watch will help either since it will
not take the circuit out of service if the watched route remains in the
routing table. The only service that allows us to do that is the backup
command. Now you mentioned before that the physical interface will have to
go down in order for the backup interface to trigger, so guess that means we
cannot use the backup command on the serial interface. What is another way
we can accomplish it?
Christian
-----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