Re: [OSL | CCIE_Voice] does MLP LFI break your wan?
Hey guys, Has anyone discovered what goes wrong with the interfaces after applying MLP LFI? I am running the same problem on my lab3. When I configure MLP LFI on both sides, the virtual interface stays up/down: Virtual-Access110.10.111.2 YES TFTP up down I have already rebooted the router several times, but it does not come up. The auto qos is applied on both sides: HQ: interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 201 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-201 auto qos voip trust fr-atm ip rsvp bandwidth 112 BR1: interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 101 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 auto qos voip trust fr-atm ip rsvp bandwidth 112 Has anyone run into this issue? Thank you, Bruno On Sat, Mar 5, 2011 at 6:51 PM, adam compton com...@gmail.com wrote: Yeah I've had this problem before. First off, you have to configure it on both sides for it to come back up. It usually comes right back up once you run auto qos voip fr-atm on both sides. If it doesn't, wr mem and reboot both routers should fix it. In proctorlabs, I haven't had to reboot the routers in this situation. In GNS3, I have to reboot them every single time. On Fri, Mar 4, 2011 at 11:01 PM, CCIE Voice cc...@corb.net wrote: I am having the exact same problem. virtual-access1, virtual-access2, and virtual-template200 are all in a down/down or up/down state. Not sure how to rectify it. Anyone else experienced this and figure out what was wrong? On Tue, Nov 23, 2010 at 12:33 PM, Romain Mullier romain.mull...@gmail.com wrote: Hi guys, was working on lab3, RSVP configuration worked well but after applying MLP LFI between HQ and BR1, I cannot bring the virtual interfaces up. Has anyone seen this before? (Routers have been reloaded) Thanks for your help. HQ class-map match-any AutoQoS-VoIP-RTP-Trust match ip dscp ef class-map match-any AutoQoS-VoIP-Control-Trust match ip dscp cs3 match ip dscp af31 ! ! policy-map AutoQoS-Policy-Trust class AutoQoS-VoIP-RTP-Trust priority 56 compress header ip rtp class AutoQoS-VoIP-Control-Trust bandwidth 17 class class-default fair-queue ! interface Serial0/0/1:0 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi ip rsvp bandwidth ! interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip pim sparse-dense-mode ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 201 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 ip rsvp bandwidth 112 ! ! interface Virtual-Template200 bandwidth 384 ip address 10.10.111.1 255.255.255.0 ip ospf mtu-ignore ppp multilink ppp multilink interleave ppp multilink fragment delay 10 service-policy output AutoQoS-Policy-Trust ip rsvp bandwidth 112 ! map-class frame-relay AutoQoS-FR-Se0/0/1:0-101 frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 frame-relay mincir 384000 ! Virtual-Access110.10.111.1 YES TFTP up*down* On BR1 ! class-map match-any AutoQoS-VoIP-RTP-Trust match ip dscp ef class-map match-any AutoQoS-VoIP-Control-Trust match ip dscp cs3 match ip dscp af31 ! ! policy-map AutoQoS-Policy-Trust class AutoQoS-VoIP-RTP-Trust priority 56 compress header ip rtp class AutoQoS-VoIP-Control-Trust bandwidth 17 class class-default fair-queue ! ! interface Serial0/0/1:0 no ip address encapsulation frame-relay IETF no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi ip rsvp bandwidth ! interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip pim sparse-dense-mode ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 101 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 auto qos voip trust fr-atm ip rsvp bandwidth 112 ! interface Virtual-Template200 bandwidth 384 ip address 10.10.111.2 255.255.255.0 ip ospf mtu-ignore ppp multilink ppp multilink interleave ppp multilink fragment delay 10 service-policy output AutoQoS-Policy-Trust ip rsvp bandwidth 112 ! ! ! map-class frame-relay AutoQoS-FR-Se0/0/1:0-101 frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 frame-relay mincir 384000 ! Virtual-Access110.10.111.2 YES TFTP up * down* ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com ___ For more information regarding industry leading CCIE Lab
Re: [OSL | CCIE_Voice] does MLP LFI break your wan?
I've run into it... Blow auto qos away and reboot, sometimes it takes 2 or 3 times, assuming the router doesn't crash when you try to remote it... -Chase -- If winners never quit and quitters never win, then who coined the phrase, Quit while you’re still ahead.? Date: Sat, 19 May 2012 12:40:17 -0300 From: brun...@gmail.com To: ccie_voice@onlinestudylist.com CC: com...@gmail.com; cc...@corb.net Subject: Re: [OSL | CCIE_Voice] does MLP LFI break your wan? Hey guys, Has anyone discovered what goes wrong with the interfaces after applying MLP LFI? I am running the same problem on my lab3. When I configure MLP LFI on both sides, the virtual interface stays up/down: Virtual-Access110.10.111.2 YES TFTP updown I have already rebooted the router several times, but it does not come up. The auto qos is applied on both sides: HQ: interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 201 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-201 auto qos voip trust fr-atm ip rsvp bandwidth 112 BR1: interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 101 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 auto qos voip trust fr-atm ip rsvp bandwidth 112 Has anyone run into this issue? Thank you, Bruno On Sat, Mar 5, 2011 at 6:51 PM, adam compton com...@gmail.com wrote: Yeah I've had this problem before. First off, you have to configure it on both sides for it to come back up. It usually comes right back up once you run auto qos voip fr-atm on both sides. If it doesn't, wr mem and reboot both routers should fix it. In proctorlabs, I haven't had to reboot the routers in this situation. In GNS3, I have to reboot them every single time. On Fri, Mar 4, 2011 at 11:01 PM, CCIE Voice cc...@corb.net wrote: I am having the exact same problem. virtual-access1, virtual-access2, and virtual-template200 are all in a down/down or up/down state. Not sure how to rectify it. Anyone else experienced this and figure out what was wrong? On Tue, Nov 23, 2010 at 12:33 PM, Romain Mullier romain.mull...@gmail.com wrote: Hi guys, was working on lab3, RSVP configuration worked well but after applying MLP LFI between HQ and BR1, I cannot bring the virtual interfaces up. Has anyone seen this before? (Routers have been reloaded) Thanks for your help. HQ class-map match-any AutoQoS-VoIP-RTP-Trust match ip dscp ef class-map match-any AutoQoS-VoIP-Control-Trust match ip dscp cs3 match ip dscp af31 ! ! policy-map AutoQoS-Policy-Trust class AutoQoS-VoIP-RTP-Trust priority 56 compress header ip rtp class AutoQoS-VoIP-Control-Trust bandwidth 17 class class-default fair-queue ! interface Serial0/0/1:0 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi ip rsvp bandwidth ! interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip pim sparse-dense-mode ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 201 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 ip rsvp bandwidth 112 ! ! interface Virtual-Template200 bandwidth 384 ip address 10.10.111.1 255.255.255.0 ip ospf mtu-ignore ppp multilink ppp multilink interleave ppp multilink fragment delay 10 service-policy output AutoQoS-Policy-Trust ip rsvp bandwidth 112 ! map-class frame-relay AutoQoS-FR-Se0/0/1:0-101 frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 frame-relay mincir 384000 ! Virtual-Access110.10.111.1 YES TFTP updown On BR1 ! class-map match-any AutoQoS-VoIP-RTP-Trust match ip dscp ef class-map match-any AutoQoS-VoIP-Control-Trust match ip dscp cs3 match ip dscp af31 ! ! policy-map AutoQoS-Policy-Trust class AutoQoS-VoIP-RTP-Trust priority 56 compress header ip rtp class AutoQoS-VoIP-Control-Trust bandwidth 17 class class-default fair-queue ! ! interface Serial0/0/1:0 no ip address encapsulation frame-relay IETF no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi ip rsvp bandwidth ! interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip pim sparse-dense-mode ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 101 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 auto qos voip trust fr-atm ip rsvp bandwidth 112 ! interface Virtual-Template200 bandwidth 384 ip address 10.10.111.2 255.255.255.0 ip ospf mtu-ignore ppp multilink ppp multilink interleave ppp multilink fragment delay 10 service-policy output AutoQoS-Policy-Trust ip rsvp bandwidth 112 ! ! ! map-class frame-relay AutoQoS-FR-Se0/0/1:0-101 frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 frame-relay
Re: [OSL | CCIE_Voice] does MLP LFI break your wan?
Bruno, save the generated config of auto-qos into a text file (class-map , policy-map, interface, ..etc) , the remove the auto-qos command under the interface. paste the config and if not worked, reboot the two routers. Khaled From: cm3_...@hotmail.com To: brun...@gmail.com; ccie_voice@onlinestudylist.com Date: Sat, 19 May 2012 12:08:12 -0500 CC: com...@gmail.com; cc...@corb.net Subject: Re: [OSL | CCIE_Voice] does MLP LFI break your wan? I've run into it... Blow auto qos away and reboot, sometimes it takes 2 or 3 times, assuming the router doesn't crash when you try to remote it... -Chase -- If winners never quit and quitters never win, then who coined the phrase, Quit while you’re still ahead.? Date: Sat, 19 May 2012 12:40:17 -0300 From: brun...@gmail.com To: ccie_voice@onlinestudylist.com CC: com...@gmail.com; cc...@corb.net Subject: Re: [OSL | CCIE_Voice] does MLP LFI break your wan? Hey guys, Has anyone discovered what goes wrong with the interfaces after applying MLP LFI? I am running the same problem on my lab3. When I configure MLP LFI on both sides, the virtual interface stays up/down: Virtual-Access110.10.111.2 YES TFTP updown I have already rebooted the router several times, but it does not come up. The auto qos is applied on both sides: HQ: interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 201 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-201 auto qos voip trust fr-atm ip rsvp bandwidth 112 BR1: interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 101 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 auto qos voip trust fr-atm ip rsvp bandwidth 112 Has anyone run into this issue? Thank you, Bruno On Sat, Mar 5, 2011 at 6:51 PM, adam compton com...@gmail.com wrote: Yeah I've had this problem before. First off, you have to configure it on both sides for it to come back up. It usually comes right back up once you run auto qos voip fr-atm on both sides. If it doesn't, wr mem and reboot both routers should fix it. In proctorlabs, I haven't had to reboot the routers in this situation. In GNS3, I have to reboot them every single time. On Fri, Mar 4, 2011 at 11:01 PM, CCIE Voice cc...@corb.net wrote: I am having the exact same problem. virtual-access1, virtual-access2, and virtual-template200 are all in a down/down or up/down state. Not sure how to rectify it. Anyone else experienced this and figure out what was wrong? On Tue, Nov 23, 2010 at 12:33 PM, Romain Mullier romain.mull...@gmail.com wrote: Hi guys, was working on lab3, RSVP configuration worked well but after applying MLP LFI between HQ and BR1, I cannot bring the virtual interfaces up. Has anyone seen this before? (Routers have been reloaded) Thanks for your help. HQ class-map match-any AutoQoS-VoIP-RTP-Trust match ip dscp ef class-map match-any AutoQoS-VoIP-Control-Trust match ip dscp cs3 match ip dscp af31 ! ! policy-map AutoQoS-Policy-Trust class AutoQoS-VoIP-RTP-Trust priority 56 compress header ip rtp class AutoQoS-VoIP-Control-Trust bandwidth 17 class class-default fair-queue ! interface Serial0/0/1:0 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi ip rsvp bandwidth ! interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip pim sparse-dense-mode ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 201 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 ip rsvp bandwidth 112 ! ! interface Virtual-Template200 bandwidth 384 ip address 10.10.111.1 255.255.255.0 ip ospf mtu-ignore ppp multilink ppp multilink interleave ppp multilink fragment delay 10 service-policy output AutoQoS-Policy-Trust ip rsvp bandwidth 112 ! map-class frame-relay AutoQoS-FR-Se0/0/1:0-101 frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 frame-relay mincir 384000 ! Virtual-Access110.10.111.1 YES TFTP updown On BR1 ! class-map match-any AutoQoS-VoIP-RTP-Trust match ip dscp ef class-map match-any AutoQoS-VoIP-Control-Trust match ip dscp cs3 match ip dscp af31 ! ! policy-map AutoQoS-Policy-Trust class AutoQoS-VoIP-RTP-Trust priority 56 compress header ip rtp class AutoQoS-VoIP-Control-Trust bandwidth 17 class class-default fair-queue ! ! interface Serial0/0/1:0 no ip address encapsulation frame-relay IETF no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi ip rsvp bandwidth ! interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip pim sparse-dense-mode ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 101 ppp Virtual-Template200 class AutoQoS
Re: [OSL | CCIE_Voice] does MLP LFI break your wan?
Once I removed the auto-qos command, the router crashed... no lucky today with that! Well, I was searching for older topics related to that on the list, and I saw one from Cristobal Priego. Basically he suggests to do the following workaround after configuring auto qos fr-atm: remove the frame-relay interface-dlci 201 ppp virtual-template 1 command re-add the command re-add the class-map to the frame-relay interface connectivity came back up Reload the HQ router. And once it comes back online again, you can reload the Branch router the number of times you want, and the virtual interface does not get down anymore. I will test that on my next remote lab. Thank you all, Bruno On Sat, May 19, 2012 at 3:17 PM, khaled Saholy khaled_sah...@hotmail.comwrote: Bruno, save the generated config of auto-qos into a text file (class-map , policy-map, interface, ..etc) , the remove the auto-qos command under the interface. paste the config and if not worked, reboot the two routers. Khaled -- From: cm3_...@hotmail.com To: brun...@gmail.com; ccie_voice@onlinestudylist.com Date: Sat, 19 May 2012 12:08:12 -0500 CC: com...@gmail.com; cc...@corb.net Subject: Re: [OSL | CCIE_Voice] does MLP LFI break your wan? I've run into it... Blow auto qos away and reboot, sometimes it takes 2 or 3 times, assuming the router doesn't crash when you try to remote it... -Chase -- If winners never quit and quitters never win, then who coined the phrase, Quit while you’re still ahead.? -- Date: Sat, 19 May 2012 12:40:17 -0300 From: brun...@gmail.com To: ccie_voice@onlinestudylist.com CC: com...@gmail.com; cc...@corb.net Subject: Re: [OSL | CCIE_Voice] does MLP LFI break your wan? Hey guys, Has anyone discovered what goes wrong with the interfaces after applying MLP LFI? I am running the same problem on my lab3. When I configure MLP LFI on both sides, the virtual interface stays up/down: Virtual-Access110.10.111.2 YES TFTP updown I have already rebooted the router several times, but it does not come up. The auto qos is applied on both sides: HQ: interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 201 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-201 auto qos voip trust fr-atm ip rsvp bandwidth 112 BR1: interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 101 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 auto qos voip trust fr-atm ip rsvp bandwidth 112 Has anyone run into this issue? Thank you, Bruno On Sat, Mar 5, 2011 at 6:51 PM, adam compton com...@gmail.com wrote: Yeah I've had this problem before. First off, you have to configure it on both sides for it to come back up. It usually comes right back up once you run auto qos voip fr-atm on both sides. If it doesn't, wr mem and reboot both routers should fix it. In proctorlabs, I haven't had to reboot the routers in this situation. In GNS3, I have to reboot them every single time. On Fri, Mar 4, 2011 at 11:01 PM, CCIE Voice cc...@corb.net wrote: I am having the exact same problem. virtual-access1, virtual-access2, and virtual-template200 are all in a down/down or up/down state. Not sure how to rectify it. Anyone else experienced this and figure out what was wrong? On Tue, Nov 23, 2010 at 12:33 PM, Romain Mullier romain.mull...@gmail.com wrote: Hi guys, was working on lab3, RSVP configuration worked well but after applying MLP LFI between HQ and BR1, I cannot bring the virtual interfaces up. Has anyone seen this before? (Routers have been reloaded) Thanks for your help. HQ class-map match-any AutoQoS-VoIP-RTP-Trust match ip dscp ef class-map match-any AutoQoS-VoIP-Control-Trust match ip dscp cs3 match ip dscp af31 ! ! policy-map AutoQoS-Policy-Trust class AutoQoS-VoIP-RTP-Trust priority 56 compress header ip rtp class AutoQoS-VoIP-Control-Trust bandwidth 17 class class-default fair-queue ! interface Serial0/0/1:0 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi ip rsvp bandwidth ! interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip pim sparse-dense-mode ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 201 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 ip rsvp bandwidth 112 ! ! interface Virtual-Template200 bandwidth 384 ip address 10.10.111.1 255.255.255.0 ip ospf mtu-ignore ppp multilink ppp multilink interleave ppp multilink fragment delay 10 service-policy output AutoQoS-Policy-Trust ip rsvp bandwidth 112 ! map-class frame-relay AutoQoS
Re: [OSL | CCIE_Voice] does MLP LFI break your wan?
Sometimes this happens, many have complained about it, some only do manual configuration, some figure out how to delete the template and reapply. It is really up to you to find what way works best for you and learn how to fix that method when you take the lab if you get MLP LFI On Sat, May 19, 2012 at 10:40 AM, Bruno Nonogaki brun...@gmail.com wrote: Hey guys, Has anyone discovered what goes wrong with the interfaces after applying MLP LFI? I am running the same problem on my lab3. When I configure MLP LFI on both sides, the virtual interface stays up/down: Virtual-Access110.10.111.2 YES TFTP updown I have already rebooted the router several times, but it does not come up. The auto qos is applied on both sides: HQ: interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 201 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-201 auto qos voip trust fr-atm ip rsvp bandwidth 112 BR1: interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 101 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 auto qos voip trust fr-atm ip rsvp bandwidth 112 Has anyone run into this issue? Thank you, Bruno On Sat, Mar 5, 2011 at 6:51 PM, adam compton com...@gmail.com wrote: Yeah I've had this problem before. First off, you have to configure it on both sides for it to come back up. It usually comes right back up once you run auto qos voip fr-atm on both sides. If it doesn't, wr mem and reboot both routers should fix it. In proctorlabs, I haven't had to reboot the routers in this situation. In GNS3, I have to reboot them every single time. On Fri, Mar 4, 2011 at 11:01 PM, CCIE Voice cc...@corb.net wrote: I am having the exact same problem. virtual-access1, virtual-access2, and virtual-template200 are all in a down/down or up/down state. Not sure how to rectify it. Anyone else experienced this and figure out what was wrong? On Tue, Nov 23, 2010 at 12:33 PM, Romain Mullier romain.mull...@gmail.com wrote: Hi guys, was working on lab3, RSVP configuration worked well but after applying MLP LFI between HQ and BR1, I cannot bring the virtual interfaces up. Has anyone seen this before? (Routers have been reloaded) Thanks for your help. HQ class-map match-any AutoQoS-VoIP-RTP-Trust match ip dscp ef class-map match-any AutoQoS-VoIP-Control-Trust match ip dscp cs3 match ip dscp af31 ! ! policy-map AutoQoS-Policy-Trust class AutoQoS-VoIP-RTP-Trust priority 56 compress header ip rtp class AutoQoS-VoIP-Control-Trust bandwidth 17 class class-default fair-queue ! interface Serial0/0/1:0 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi ip rsvp bandwidth ! interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip pim sparse-dense-mode ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 201 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 ip rsvp bandwidth 112 ! ! interface Virtual-Template200 bandwidth 384 ip address 10.10.111.1 255.255.255.0 ip ospf mtu-ignore ppp multilink ppp multilink interleave ppp multilink fragment delay 10 service-policy output AutoQoS-Policy-Trust ip rsvp bandwidth 112 ! map-class frame-relay AutoQoS-FR-Se0/0/1:0-101 frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 frame-relay mincir 384000 ! Virtual-Access110.10.111.1 YES TFTP up*down* On BR1 ! class-map match-any AutoQoS-VoIP-RTP-Trust match ip dscp ef class-map match-any AutoQoS-VoIP-Control-Trust match ip dscp cs3 match ip dscp af31 ! ! policy-map AutoQoS-Policy-Trust class AutoQoS-VoIP-RTP-Trust priority 56 compress header ip rtp class AutoQoS-VoIP-Control-Trust bandwidth 17 class class-default fair-queue ! ! interface Serial0/0/1:0 no ip address encapsulation frame-relay IETF no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi ip rsvp bandwidth ! interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip pim sparse-dense-mode ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 101 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 auto qos voip trust fr-atm ip rsvp bandwidth 112 ! interface Virtual-Template200 bandwidth 384 ip address 10.10.111.2 255.255.255.0 ip ospf mtu-ignore ppp multilink ppp multilink interleave ppp multilink fragment delay 10 service-policy output AutoQoS-Policy-Trust ip rsvp bandwidth 112 ! ! ! map-class frame-relay AutoQoS-FR-Se0/0/1:0-101 frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 frame-relay mincir 384000 ! Virtual-Access110.10.111.2 YES TFTP up * down*
Re: [OSL | CCIE_Voice] does MLP LFI break your wan?
Yeah I've had this problem before. First off, you have to configure it on both sides for it to come back up. It usually comes right back up once you run auto qos voip fr-atm on both sides. If it doesn't, wr mem and reboot both routers should fix it. In proctorlabs, I haven't had to reboot the routers in this situation. In GNS3, I have to reboot them every single time. On Fri, Mar 4, 2011 at 11:01 PM, CCIE Voice cc...@corb.net wrote: I am having the exact same problem. virtual-access1, virtual-access2, and virtual-template200 are all in a down/down or up/down state. Not sure how to rectify it. Anyone else experienced this and figure out what was wrong? On Tue, Nov 23, 2010 at 12:33 PM, Romain Mullier romain.mull...@gmail.com wrote: Hi guys, was working on lab3, RSVP configuration worked well but after applying MLP LFI between HQ and BR1, I cannot bring the virtual interfaces up. Has anyone seen this before? (Routers have been reloaded) Thanks for your help. HQ class-map match-any AutoQoS-VoIP-RTP-Trust match ip dscp ef class-map match-any AutoQoS-VoIP-Control-Trust match ip dscp cs3 match ip dscp af31 ! ! policy-map AutoQoS-Policy-Trust class AutoQoS-VoIP-RTP-Trust priority 56 compress header ip rtp class AutoQoS-VoIP-Control-Trust bandwidth 17 class class-default fair-queue ! interface Serial0/0/1:0 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi ip rsvp bandwidth ! interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip pim sparse-dense-mode ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 201 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 ip rsvp bandwidth 112 ! ! interface Virtual-Template200 bandwidth 384 ip address 10.10.111.1 255.255.255.0 ip ospf mtu-ignore ppp multilink ppp multilink interleave ppp multilink fragment delay 10 service-policy output AutoQoS-Policy-Trust ip rsvp bandwidth 112 ! map-class frame-relay AutoQoS-FR-Se0/0/1:0-101 frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 frame-relay mincir 384000 ! Virtual-Access110.10.111.1 YES TFTP up*down* On BR1 ! class-map match-any AutoQoS-VoIP-RTP-Trust match ip dscp ef class-map match-any AutoQoS-VoIP-Control-Trust match ip dscp cs3 match ip dscp af31 ! ! policy-map AutoQoS-Policy-Trust class AutoQoS-VoIP-RTP-Trust priority 56 compress header ip rtp class AutoQoS-VoIP-Control-Trust bandwidth 17 class class-default fair-queue ! ! interface Serial0/0/1:0 no ip address encapsulation frame-relay IETF no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi ip rsvp bandwidth ! interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip pim sparse-dense-mode ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 101 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 auto qos voip trust fr-atm ip rsvp bandwidth 112 ! interface Virtual-Template200 bandwidth 384 ip address 10.10.111.2 255.255.255.0 ip ospf mtu-ignore ppp multilink ppp multilink interleave ppp multilink fragment delay 10 service-policy output AutoQoS-Policy-Trust ip rsvp bandwidth 112 ! ! ! map-class frame-relay AutoQoS-FR-Se0/0/1:0-101 frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 frame-relay mincir 384000 ! Virtual-Access110.10.111.2 YES TFTP up * down* ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
Re: [OSL | CCIE_Voice] does MLP LFI break your wan?
I am having the exact same problem. virtual-access1, virtual-access2, and virtual-template200 are all in a down/down or up/down state. Not sure how to rectify it. Anyone else experienced this and figure out what was wrong? On Tue, Nov 23, 2010 at 12:33 PM, Romain Mullier romain.mull...@gmail.comwrote: Hi guys, was working on lab3, RSVP configuration worked well but after applying MLP LFI between HQ and BR1, I cannot bring the virtual interfaces up. Has anyone seen this before? (Routers have been reloaded) Thanks for your help. HQ class-map match-any AutoQoS-VoIP-RTP-Trust match ip dscp ef class-map match-any AutoQoS-VoIP-Control-Trust match ip dscp cs3 match ip dscp af31 ! ! policy-map AutoQoS-Policy-Trust class AutoQoS-VoIP-RTP-Trust priority 56 compress header ip rtp class AutoQoS-VoIP-Control-Trust bandwidth 17 class class-default fair-queue ! interface Serial0/0/1:0 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi ip rsvp bandwidth ! interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip pim sparse-dense-mode ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 201 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 ip rsvp bandwidth 112 ! ! interface Virtual-Template200 bandwidth 384 ip address 10.10.111.1 255.255.255.0 ip ospf mtu-ignore ppp multilink ppp multilink interleave ppp multilink fragment delay 10 service-policy output AutoQoS-Policy-Trust ip rsvp bandwidth 112 ! map-class frame-relay AutoQoS-FR-Se0/0/1:0-101 frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 frame-relay mincir 384000 ! Virtual-Access110.10.111.1 YES TFTP up *down* On BR1 ! class-map match-any AutoQoS-VoIP-RTP-Trust match ip dscp ef class-map match-any AutoQoS-VoIP-Control-Trust match ip dscp cs3 match ip dscp af31 ! ! policy-map AutoQoS-Policy-Trust class AutoQoS-VoIP-RTP-Trust priority 56 compress header ip rtp class AutoQoS-VoIP-Control-Trust bandwidth 17 class class-default fair-queue ! ! interface Serial0/0/1:0 no ip address encapsulation frame-relay IETF no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi ip rsvp bandwidth ! interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip pim sparse-dense-mode ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 101 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 auto qos voip trust fr-atm ip rsvp bandwidth 112 ! interface Virtual-Template200 bandwidth 384 ip address 10.10.111.2 255.255.255.0 ip ospf mtu-ignore ppp multilink ppp multilink interleave ppp multilink fragment delay 10 service-policy output AutoQoS-Policy-Trust ip rsvp bandwidth 112 ! ! ! map-class frame-relay AutoQoS-FR-Se0/0/1:0-101 frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 frame-relay mincir 384000 ! Virtual-Access110.10.111.2 YES TFTP up * down* ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
[OSL | CCIE_Voice] does MLP LFI break your wan?
Hi guys, was working on lab3, RSVP configuration worked well but after applying MLP LFI between HQ and BR1, I cannot bring the virtual interfaces up. Has anyone seen this before? (Routers have been reloaded) Thanks for your help. HQ class-map match-any AutoQoS-VoIP-RTP-Trust match ip dscp ef class-map match-any AutoQoS-VoIP-Control-Trust match ip dscp cs3 match ip dscp af31 ! ! policy-map AutoQoS-Policy-Trust class AutoQoS-VoIP-RTP-Trust priority 56 compress header ip rtp class AutoQoS-VoIP-Control-Trust bandwidth 17 class class-default fair-queue ! interface Serial0/0/1:0 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi ip rsvp bandwidth ! interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip pim sparse-dense-mode ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 201 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 ip rsvp bandwidth 112 ! ! interface Virtual-Template200 bandwidth 384 ip address 10.10.111.1 255.255.255.0 ip ospf mtu-ignore ppp multilink ppp multilink interleave ppp multilink fragment delay 10 service-policy output AutoQoS-Policy-Trust ip rsvp bandwidth 112 ! map-class frame-relay AutoQoS-FR-Se0/0/1:0-101 frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 frame-relay mincir 384000 ! Virtual-Access110.10.111.1 YES TFTP up *down* On BR1 ! class-map match-any AutoQoS-VoIP-RTP-Trust match ip dscp ef class-map match-any AutoQoS-VoIP-Control-Trust match ip dscp cs3 match ip dscp af31 ! ! policy-map AutoQoS-Policy-Trust class AutoQoS-VoIP-RTP-Trust priority 56 compress header ip rtp class AutoQoS-VoIP-Control-Trust bandwidth 17 class class-default fair-queue ! ! interface Serial0/0/1:0 no ip address encapsulation frame-relay IETF no fair-queue frame-relay traffic-shaping frame-relay lmi-type ansi ip rsvp bandwidth ! interface Serial0/0/1:0.1 point-to-point bandwidth 384 ip pim sparse-dense-mode ip ospf mtu-ignore snmp trap link-status frame-relay interface-dlci 101 ppp Virtual-Template200 class AutoQoS-FR-Se0/0/1:0-101 auto qos voip trust fr-atm ip rsvp bandwidth 112 ! interface Virtual-Template200 bandwidth 384 ip address 10.10.111.2 255.255.255.0 ip ospf mtu-ignore ppp multilink ppp multilink interleave ppp multilink fragment delay 10 service-policy output AutoQoS-Policy-Trust ip rsvp bandwidth 112 ! ! ! map-class frame-relay AutoQoS-FR-Se0/0/1:0-101 frame-relay cir 384000 frame-relay bc 3840 frame-relay be 0 frame-relay mincir 384000 ! Virtual-Access110.10.111.2 YES TFTP up *down * ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
