From: David Wolsefer (wolsefer@xxxxxxxxxxxxxxxx)
Date: Tue Dec 05 2000 - 20:34:29 GMT-3
Why not make the loopback addresses the source of the peering. Since they
will always be up, if a normal WAN link goes down, then ISDN should be
configured to come up, probably best with a floating static route. If you
want to run BGP, then the ISDN link is going to be up all the time when the
normal WAN link goes down. I don't think there is a way to maintain the TCP
connection unless the ISDN link is up. Perhaps you could mess with some
timers or something.
It is not really clear to me what you want to accomplish. It also seems a
bit strange to back up an Ethernet link with ISDN, although it does bring up
some interesting routing issues because what if the Ethernet for each router
is plugged into a switch and the cable for the other router was pulled from
the switch. The local Ethernet interface on the router would still be up up,
hence, my reasoning for floating static routes.
Regards,
David Wolsefer, CCIE #5858
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Rob Barton
Sent: Tuesday, December 05, 2000 9:14 AM
To: Ronnie Royston
Cc: Ccielab
Subject: RE: BGP on demand
When the main line goes down and the ISDN line comes up due to some backup
interface algorithm, then the BGP speakers will establish a TCP session
between themselves over the ISDN link, thus allowing the BGP routes to be
propogated. When the ISDN line is down, I assume the BGP updates will come
through the normal WAN link. The issue is to make sure that BGP doesn't
bring up the ISDN line all the time, and I think the way to do it would be
to prevent BGP speakers from forming peer relationships by making BGP
uninteresting.
I haven't actually tried this in my lab yet, but when the TCP session
establishes itself over the ISDN line, won't the established TCP session
keep up the line until the main interface comes back up?
Any ideas on this?
Cheers, Rob.
-----Original Message-----
From: Ronnie Royston [mailto:RonnieR@globaldatasys.com]
Sent: Tuesday, December 05, 2000 12:04 PM
To: 'Rob Barton'; Ccielab; Steve Clubb
Subject: RE: BGP on demand
Rob, can you explain how the BGP session will not time out after the idle
timer expires no the ISDN interface? Would OSPF set DoNotAge on the BGP
routes in the route table as well?
-----Original Message-----
From: Rob Barton [mailto:robbarto@cisco.com]
Sent: Tuesday, December 05, 2000 5:12 AM
To: Ccielab; Steve Clubb
Subject: RE: BGP on demand
You would want to prevent BGP information from bringing up the line by
making the BGP traffic uninteresting. BGP sessions are established with TCP
port 179, so just write a dialer-list to make this kind of traffic
uninteresting.
Cheers, Rob.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Steve Clubb
Sent: Monday, December 04, 2000 4:39 PM
To: ccielab@groupstudy.com
Subject: BGP on demand
I have a ibgp router (route-reflector 'client') that has a primary
connection on it's ethernet interface, but also has an isdn link for
back-up. If the ethernet link goes down and the bri interface comes up on
demand, is there a way to stop the ibgp router from keeping up the back-up
link without loosing it's tcp connection with it's peer?
r1 and r2 configs relevant to this question:
r1
interface loopback0
ip add 131.10.100.1 255.255.255.0
!
router bgp 2
neighbor 131.10.130.2 remote-as 2
neighbor 131.10.130.2 update-source Loopback0
neighbor 131.10.130.2 route-reflector-client
!
r2
!
interface Loopback0
ip address 131.10.130.2 255.255.255.0
!
interface BRI0
ip address 131.10.132.2 255.255.255.0
ip ospf demand-circuit
isdn spid1 40888830000101
isdn spid2 40888830000102
dialer map ip 131.10.132.3 name r3 broadcast 8887000
dialer-group 1
!
router bgp 2
neighbor 131.10.100.1 remote-as 2
neighbor 131.10.100.1 update-source Loopback0
****after the e0 is shut, the link comes up constantly****
debug di pack
BRI0: sending broadcast to ip 137.20.132.5 -- failed, not connected
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:25:59 GMT-3