From: Erick B. (erickbe@xxxxxxxxx)
Date: Tue Apr 17 2001 - 13:10:14 GMT-3
In my experience, I've found a point-to-point sub
interface and dial backup not to be that reliable. Ie:
The backup link didn't come up in a timely manner or
at all.
But using the Frame Relay End-To-End Keepalive feature
starting in 12.0(5)T resolves the issue and dial
backup kicks in right away when the PVC goes down.
--- "Gonzales, Enrique"
<Enrique.Gonzales@getronics.com> wrote:
> Actually, backup command will work with frame-relay
> you are just resticted
> on
> how you use the command.
>
> When a serial interface is configured for
> frame-relay there are two things
> that
> keep that interface in an up/up state. The first is
> the carrier-detect.
> The
> second would be the lmi packets that it is
> exchanging with the telco
> frame-relay
> switch. As long as the interface does not loose
> carrier and recieves
> replies to
> it's lmi inqueries then the interface will stay
> regardless of the pvc
> status. So,
> the physical interface is not affected by the status
> of the pvc. Imagine a
> site
> that has multiple remote sites configured in a hub
> and spoke fashion. If
> one site
> where to go deleted and the interface where to go to
> up/dn then all the
> sites would
> be affected. This is not the case. The only thing
> that would happen is
> that the
> frame-rely switch would report a status change in
> the lmi packets. That is
> why you
> are never to use the backup command on a physical or
> multi-point frame-relay
> interface.
> On the other hand if you configure a frame-relay
> point-to-point
> sub-interface then the
> backup command would work. The sub-interface
> actually relies on the status
> of the pvc.
> If the status is anything other than active it will
> go to dn/dn.
>
> I hope this helps.
>
> Henry
>
> -----Original Message-----
> From: Chris Mott [mailto:cmott@home.com]
> Sent: Tuesday, April 17, 2001 8:19 AM
> To: CCIE; Daniel C. Young
> Subject: RE: ISDN backup interface
>
>
> In real life, IMHO, I would never use the
> dial-backup command in the first
> place! Floating statics and Dialer-watch work the
> real life stuff better
> ... consider the FR circuit whereby the PVC gets
> deleted, but power is still
> supplied to the interface via the last-mile local
> loop ... you get Serial 0
> Up/Down, which is _not_ enough to trigger the
> dial-backup ... also, lest we
> forget, when a BRI interface is used as dial-backup,
> it is then incapable of
> other uses as it is held strictly for that use ...
> of course all of this has
> been mentioned before and can be found in the
> archives, so m'apolgie!
>
> -----Original Message-----
> From: nobody@groupstudy.com
> [mailto:nobody@groupstudy.com]On Behalf Of
> Daniel C. Young
> Sent: Friday, March 30, 2001 12:07 AM
> To: 'Alan Basinger'; 'Devender Singh'; 'Groupstudy
> Lab'
> Subject: RE: ISDN backup interface
>
>
> Alan,
>
> Thanks for your input. You brought up issues I had
> not considered.
>
> Now if I may, an argument in defense of my position.
> My suggestions are,
> first and foremost, for a lab application. Your
> concerns are quite valid for
> real life scenarios. However, after giving this a
> bit more thought, I'm not
> quite sure that I entirely agree with you, both from
> a technical and an
> economical standpoint.
>
> Even in real life, should the serial link go down
> (let's hope that it
> doesn't) the ISDN line will only serve as a
> temporary solution. After all,
> this is why a company would select an ISDN line over
> a (more expensive)
> point-to-point backup link or even other (cheaper)
> broadband services
> nowadays. Assuming that the serial line is quite
> stable, ISDN cost is a
> non-issue in the long run (averaged per-month). If
> ISDN costs begin to rise,
> this gives signals that perhaps the serial line
> carrier is not meeting SLA
> agreements.
>
> I agree with you, though, that the called router
> need not have a dialer
> string. However, lenghtening the idle time will
> ensure that the link won't
> flap in the event that line comes up for backup.
> Since we do not define
> interesting traffic on the called router, the
> calling router is insured
> total control over link connect/disconnect.
>
> Daniel Young
> Sr. Network Engineer
> Internet Data Center
> SBC Service Inc. - ITO
>
> (949) 221-1928 Office
> (714) 350-8945 Cell
> ICQ# 109846891
>
>
> -----Original Message-----
> From: Alan Basinger [mailto:abasinge@swbell.net]
> Sent: Thursday, March 29, 2001 9:24 PM
> To: Daniel C. Young; 'Devender Singh'; 'Groupstudy
> Lab'
> Subject: RE: ISDN backup interface
>
>
> Daniel,
> If you are using this as a backup and the call is
> going to be placed one way
> only when the ser2 goes down then keep the
> interesting traffic on the called
> router r2504 and remove the dial string so it will
> not initiate the call
> ever but will keep the line up if it has data to
> send only after r2522
> places the call because ser2 has failed. You want
> the call initiated from
> the router that has the backup command on the
> interface correct?
> Therefore there is no reason to have a dial string
> on the other end on
> r2504, but there is a reason not to have and idle
> time as long as the sun is
> in the sky. It is called long distance charges and
> even in some cases local
> toll charges. For ISDN these can be sky high. (much
> more than a pots line).
> DDR is the best solution for dial backup when done
> correctly because it only
> brings the line up when there is data. ( Your
> mission Jim if you choose to
> accept it is to design a very good dialer-list ). It
> is common to shorten
> the idle time so that the line goes down sooner if
> there is no traffic. When
> it costs 25 cents or more a minute to keep the line
> up and after one e-mail
> message comes across your keeping the line up for 11
> days or till the ser 2
> comes back up even if there is no data? Sorry but my
> customers would kill me
> and find a new engineer as well as phone company.
> How about this scenario? The line comes up sends the
> packets and then goes
> down till more interesting traffic is seen. Then the
> customer pays only for
> data sent... Not trying to be rude just a little
> education on ISDN DDR and
> the costs associated. Hope this helps....
>
> Alan Basinger
> Systems Engineer
> SBC DataComm
> Houston Texas
> abasinge@swbell.net
>
> | |
> ||| |||
> .|||||. .|||||.
> .:|||||||||:.:|||||||||:.
> C i s c o S y s t e m s
> Certified Gold Partner
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com
> [mailto:nobody@groupstudy.com]On Behalf Of
> Daniel C. Young
> Sent: Thursday, March 29, 2001 11:06 PM
> To: 'Devender Singh'; 'Groupstudy Lab'
> Subject: RE: ISDN backup interface
>
>
> Devender,
>
> Of course, you can disagree with me. The key here,
> of course, is to define a
> REALLY long idle time on the called router, such as
> 2147483. This will keep
> it up for 11 days without flapping, unless of
> course, the primary link goes
> back up. In that case, the calling router will
> terminate the link. This is
> what we want.
>
> Does this make sense? I'd like to know what your
> thoughts are.
>
> Daniel Young
> Sr. Network Engineer
> Internet Data Center
> SBC Service Inc. - ITO
>
> (949) 221-1928 Office
> (714) 350-8945 Cell
> ICQ# 109846891
>
>
> -----Original Message-----
> From: nobody@groupstudy.com
> [mailto:nobody@groupstudy.com]On Behalf Of
> Devender Singh
> Sent: Wednesday, March 28, 2001 11:41 PM
> To: Daniel C. Young; 'Groupstudy Lab'
> Subject: RE: ISDN backup interface
>
>
> Daniel,
>
>
> Can I disgree with you with what you going to write
> in your LBB. If other
> side does no have interesting traffic, what happen
> after idle time out once
> the link is up. This will cause the link to flap.
>
> cheers
>
> Devender Singh
> BE(Hons), CCNP
> IP Solution Specialist
>
>
> -----Original Message-----
> From: Daniel C. Young
> [mailto:danyoung99@mediaone.net]
> Sent: Thursday, 29 March 2001 3:43
> To: 'Groupstudy Lab'
> Subject: RE: ISDN backup interface
>
>
>
> Group,
>
> Many thanks for the fantastic response! You guys are
> great.
>
> Here's how I was able to resolve it:
> -added 'broadcast' parameter to 'dialer map'
> -added 'name r25XX' parameter to 'dialer map'
> (although I don't think that
> this one was crucial.
>
> Also, a couple of new tips I learned from the
> "Little Black Book" by
> Rudenko:
> -Dialed router should NOT have interested traffic
> defined. Otherwise, it
> tries to bring the dialer interface up each time
> interesting traffic needs
> to cross the dialup connection. Rudenko even
> suggests coding a 'dialer-list
> # protocol ip DENY' on the counterpart router.
>
> Again, thank you all.
>
> Regards,
>
> Daniel Young
> Sr. Network Engineer
> SBC Internet Data Center
> ICQ# 109846891
>
> *** First attempt: San Jose - June 13, 2001 ***
>
>
> -----Original Message-----
> From: nobody@groupstudy.com
> [mailto:nobody@groupstudy.com]On Behalf Of
> David Bader
> Sent: Wednesday, March 28, 2001 10:22 AM
> To: Groupstudy Lab; adiment@uswest.com
> Subject: AW: ISDN backup interface
>
>
> Hi Daniel
>
> there are several issues to talk about. first you
> have to be aware that the
> backup command only sets bri0 in backup mode, which
> means it comes up if the
> serial dies. but you have to make sure your routing
> will work in this case.
> and you have no routes for your backup interface.
>
>
>
> --------------- 1.1.1.0/24
> | routing table r2522: R
> 10.0.0.0/8 192.168.0.2
> (120)
> |.1 C
> 1.1.1.0/24
> r2522---- .1 C
> 192.168.0.0/24
> |.1 | *C
> 10.1.1.0/24
> 192.168.0.0/24 | | 10.1.1.0/24
> | |
> |.2 |
> r2504---- .2 routing table r2504: R
> 1.0.0.0/8 192.168.0.1
> (120)
> |.1 C
> 192.168.0.0/24
> | C
> 10.3.0.0/16
> *C 10.1.1.0/24
>
> ok, now to the picture. i think you end up with this
> routing table, without
> the connected route with the *. it wouldn't have any
> effect if you use a
> class C on your TR because RIP I by default does
> auto-summary and you cannot
> turn it off. first you need the command broadcast to
> allow rip to run, when
> the bri comes up. if your bri comes alive (serial
> goes down) the *routes are
> created. and if you add a static route 10.3.0.0/16
> 10.1.1.2 to router r2522
> this route would also appear in your table at this
> time. so, now you have a
> route to 10.3.0.0 which is used on your backup
> interface. on the other side
> you need off course a route 1.1.1.0/24 10.1.1.1 to
> provide a way back. hope
> this works !!!
>
> another thing, you have to provide the name of the
> remote router in your map
> command, otherwise you will run into problems if you
> connect with more than
> one channel. the used channels are remembered with
> the hostname of the
> remote router.
>
> wish you much success, let me know if it worked.
>
>
> --dave
>
> -----Ursprungliche Nachricht-----
> Von: nobody@groupstudy.com
> [mailto:nobody@groupstudy.com]Im Auftrag von
> adiment@uswest.com
> Gesendet: Mittwoch, 28. Marz 2001 16:59
> An: ccielab@groupstudy.com
> Betreff: RE: ISDN backup interface
>
>
>
> 1. Source the ping from a lan interface on the
> originating router. If you
> source it from the serial and it goes down it
> probably won't be sending a
> ping.
>
> 2. Use a class C mask for T/R interface.
>
> 3. Rip will not work because there is no
> "broadcast" statement in your
> dialer map command.
>
>
> -----Original Message-----
> From: Daniel C. Young
> [mailto:danyoung99@mediaone.net]
> Sent: Wednesday, March 28, 2001 1:31 AM
> To: ccielab@groupstudy.com
> Subject: ISDN backup interface
>
>
> Group,
>
> I'm having problems getting an ISDN bri interface to
> backup a serial
> interface. Here's the scenario:
>
> r2522
> | |
> | ISDN (backup)
> | |
> r2504
>
> Both routers run rip advertising all networks. I
> perform a continuous ping
> >from to r2504's TR int via the serial interface. In
> the middle, I pull the
> cable and the BRI ints are supposed to come up.
> Instead, I get:
>
> Sending 1000, 100-byte ICMP Echos to 10.3.1.1,
> timeout is 2 seconds:
>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.
> 03:25:21: %LINK-3-UPDOWN: Interface Serial2, changed
> state to down
> 03:25:22: %LINEPROTO-5-UPDOWN: Line protocol on
> Interface Serial2, changed
> state
> to down..
> 03:25:26: %LINK-3-UPDOWN: Interface BRI0:1, changed
> state to down
> 03:25:26: %LINK-3-UPDOWN: Interface BRI0:2, changed
> state to down
> 03:25:26: %LINK-3-UPDOWN: Interface BRI0, changed
> state to up
> 03:25:26: %ISDN-6-LAYER2UP: Layer 2 for Interface
> BR0, TEI 64 changed to up
> 03:25:26: ISDN BR0: TX -> INFORMATION pd = 8
> callref = (null)
> SPID Information i = '3840000001'
> 03:25:26: ISDN BR0: RX <- INFORMATION pd = 8
> callref = (null)
> ENDPOINT IDent i = 0x8181
> 03:25:26: ISDN BR0: Received .
> EndPoint ID
> 03:25:26: %ISDN-6-LAYER2UP: Layer 2 for Interface
> BR0, TEI 65 changed to up
> 03:25:26: ISDN BR0: TX -> INFORMATION pd = 8
> callref = (null)
> SPID Information i = '3840000002'
> 03:25:26: ISDN BR0: RX <- INFORMATION pd = 8
> callref = (null)
> ENDPOINT IDent i = 0x8282
> 03:25:26: ISDN BR0: Received EndPoint
> ID..........................
>
> It just hangs here...now once, I plug the cable back
> in everything else
> comes back up as normal:
> 03:35:21: %LINK-3-UPDOWN: Interface Serial2, changed
> state to up.
> 03:35:22: %LINEPROTO-5-UPDOWN: Line protocol on
> Interface Serial2, changed
> state
> to up.........
> 03:35:41: %ISDN-6-LAYER2DOWN: Layer 2 for Interface
> BRI0, TEI 64 changed to
> down
>
> 03:35:41: %ISDN-6-LAYER2DOWN: Layer 2 for Interface
> BRI0, TEI 65 changed to
> down
>
> 03:35:41: %LINK-5-CHANGED: Interface BRI0, changed
> state to standby mode
> 03:35:41: %LINK-3-UPDOWN: Interface BRI0:1, changed
> state to down
> 03:35:41: %LINK-3-UPDOWN: Interface BRI0:2, changed
> state to
> down.!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!
> Success rate is 85 percent (852/1000), round-trip
> min/avg/max = 28/28/152 ms
>
> If I take off the backup commands on the serial
> interface, the router dials
> just fine and everybody is happy, which leads me to
> believe that SPIDs and
> phone numbers are OK.
>
> Configs:
> [r2522]
> hostname r2522
> !
> username r2504 password 0 cisco
> isdn switch-type basic-ni
> !
> interface Ethernet0
> ip address 1.1.1.1 255.255.255.0
> no ip directed-broadcast
> no keepalive
> !
> interface Serial2
> backup delay 5 20
> backup interface BRI0
> ip address 192.168.0.1 255.255.255.0
> no ip directed-broadcast
> clockrate 72000
> !
> interface BRI0
> ip address 10.1.1.1 255.255.255.0
> no ip directed-broadcast
> encapsulation ppp
> dialer idle-timeout 90
> dialer map ip 10.1.1.2 384020
> dialer load-threshold 1 outbound
> dialer-group 1
> isdn switch-type basic-ni
> isdn spid1 3840000001 384000
> isdn spid2 3840000002 384010
> ppp authentication chap
> ppp multilink
> !
> router rip
> network 1.0.0.0
> network 10.0.0.0
> network 192.168.0.0
> !
> dialer-list 1 protocol ip permit
>
> [r2504]
> hostname r2504
> !
> username r2522 password 0 cisco
> isdn switch-type basic-ni
> !
> interface Serial0
> ip address 192.168.0.2 255.255.255.0
> no ip directed-broadcast
> no ip mroute-cache
> no fair-queue
> !
> interface TokenRing0
> ip address 10.3.1.1 255.255.0.0
> no ip directed-broadcast
> ring-speed 16
> !
> interface BRI0
> ip address 10.1.1.2 255.255.255.0
> no ip directed-broadcast
> encapsulation ppp
> dialer idle-timeout 90
> dialer map ip 10.1.1.1 384000
> dialer load-threshold 1 outbound
> dialer-group 1
> isdn switch-type basic-ni
> isdn spid1 3840200001 384020
> isdn spid2 3840200002 384030
> ppp authentication chap
> ppp multilink
> !
> router rip
> network 10.0.0.0
> network 192.168.0.0
> !
> dialer-list 1 protocol ip permit
>
> Any advices? Thanks...
>
> Daniel Young
> Sr. Network Engineer
> SBC Internet Data Center
> ICQ# 109846891
>
> *** First attempt: San Jose - June 13, 2001 ***
>
> **NOTE** All LAB SWAP messages should now be sent to
> the
> LAB SWAP Message board on groupstudy.com.
> **NOTE** All LAB SWAP messages should now be sent to
> the
> LAB SWAP Message board on groupstudy.com.
> **NOTE** All LAB SWAP messages should now be sent to
> the
> LAB SWAP Message board on groupstudy.com.
> **NOTE** All LAB SWAP messages should now be sent to
> the
> LAB SWAP Message board on groupstudy.com.
> **NOTE** All LAB SWAP messages should now be sent to
> the
> LAB SWAP Message board on groupstudy.com.
> **NOTE** All LAB SWAP messages should now be sent to
> the
> LAB SWAP Message board on groupstudy.com.
> **NOTE** All LAB SWAP messages should now be sent to
> the
> LAB SWAP Message board on groupstudy.com.
> **Please
> read:http://www.groupstudy.com/list/posting.html
> **Please
> read:http://www.groupstudy.com/list/posting.html
>
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:29:48 GMT-3