11-26-2008 10:50 AM - edited 03-04-2019 12:30 AM
All I have the following configuration on our router Cisco 2821 c2800nm-advsecurityk9-mz.124-10c.bin.
controller T1 0/0/0
framing esf
linecode b8zs
cablelength short 133
channel-group 0 timeslots 1-24
!
controller T1 0/0/1
framing esf
linecode b8zs
cablelength short 133
channel-group 0 timeslots 1-24
interface Serial0/0/0:0
bandwidth 1536
no ip address
no ip redirects
no ip proxy-arp
encapsulation frame-relay MFR1
load-interval 30
no arp frame-relay
hold-queue 256 out
!
interface Serial0/0/1:0
bandwidth 1536
no ip address
no ip redirects
no ip proxy-arp
encapsulation frame-relay MFR1
load-interval 30
no arp frame-relay
hold-queue 256 out
interface MFR1
no ip address
no ip redirects
no ip proxy-arp
encapsulation frame-relay IETF
no ip mroute-cache
load-interval 30
no arp frame-relay
frame-relay lmi-type ansi
!
interface MFR1.500 point-to-point
ip address 192.168.1.42 255.255.255.252
ip access-group INTERNET_IN in
no ip redirects
no ip proxy-arp
ip virtual-reassembly max-reassemblies 32
no cdp enable
no arp frame-relay
frame-relay interface-dlci 500 IETF
Why is it if one of the T1 circuits goes down it takes the entire MFR Frame interface down. Is there a way to prevent this?
After only 1 of the T1's takes a hit the MFR Frame PVC goes down with it too. Should it do this?
Are there configurations that prevent this from happening?
12-03-2008 07:04 AM
Your problem seems to be Bug. CSCec29960
With multiple serial interfaces provisioned as part of a given MFR bundle, shutting down serial interfaces in the MFR bundle may cause other bundle interfaces to go down and subsequently
the MFR interface itself my go down.
Try this steps to take to solve this issue:
1. Check config
2. CHeck interfaces
3. Check hardware
Please verify the remote end configuration also.
Try to upgrade your IOS to resolve your issue.
12-04-2008 12:25 PM
I checked on this bug ID and our IOS version is not affected. This does not appear to be the problem. Thanks for your reply though.
12-04-2008 03:50 PM
Do you know what the platform on the other side is? What kind of card is present there?
It should not be doing that. We need to check who is requesting the MFR to be brought down.
Any chance of enabling debugs on this? "debug frame-relay multilink [control [mfr number | serial number]]" might help in determining this.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide