Here's what I recieved when I tried looking up this Bug ID.......
Dear valued Cisco Bug Toolkit customer, the bug ID CSCsr27209 you searched contains proprietary information that cannot be disclosed at this time; therefore, we are unable to display the bug details. Please note it is our policy to make all externally-facing bugs available in Bug Toolkit to best assist our customers. As a result, the system administrators have been automatically alerted to the problem.
While we are working to resolve this issue, we invite you to reach out to the experts on the Bug Toolkit Support Community. You may find answers there to your Bug Toolkit questions, or post your feedback on our forum as well. Thank you.
I'm kind of curious about why this is. But I'm really interested in knowing about this bug because it involves VDSL technology that I'm trying to implement at work and now I may be forced to wait on a resolution.
Thanks to anyone, and everyone, who is interested and willing to assist.
To better assist you with below case, can you please let me know, how did you get awareness about "CSCsr27209" ?
What you are seeing in Bug Toolkit is correct. "CSCsr27209" is assigned to an internal project and not to externally found bug/scenario/case hence this bug is not available in Bug Toolkit database.
This bug is in reference where end users should not be able to configure ATM on Cisco 88x series routers as it is not a supported. Also this bug is already fixed and verified, and if you use any of the latest 15.xT image you should not encounter this bug.
It's interesting that you've noted the bug has already been fixed (that's great news). I just learned about the bug last night through a TAC engineer. I have 2 of the 887v routers to work with. I have over 50 of the 887 (using ADSL2/2+ over POTS (Annex A)) in the field working now with a combination of ISPs (AT&T, Centurylink, and Windstream). With the introduction of AT&T's Uverse, there is a growing desire to use the technology in the same project (DMVPN network using the CVO/ECT design as a model). That's how this all came about.
I've configured the first 887v for this network, but the ATM interface doesn't show up in the router. I opened a TAC case yesterday and the engineer that owns my case gave me a work around using the 'ethernet 0' interface in place of the ATM interface.
Now. This particular router (1 of the 2 887v routers) is at a remote location where Uverse is available (my boss's home to be exact). There he has 2 DSL lines (one ADSL2 and one VDSL2). This allows me to have a tunnel up to the 887v through the ADSL2 line in a 'pass through' method until I can get the VDSL line to authenticate properly with the router's dialer interface. However, it's not always online. He's just being gracious enough to let me test with it when he can spare the ADSL2 line.
Is this a better explaination?
I do have the other 887V router here on my desk and I'm about to look at the version of code it has.
Thanks so much for your assistance!
I opened a TAC case yesterday and the engineer that owns my case gave me a work around using the 'ethernet 0' interface in place of the ATM interface.
I also got this cleared up this morning (I've haven't had a chance to test anymore since my first post).
As of now, (running 124.T) the physical VDSL interface shows up as Ethernet 0, instead of ATM 0. There is no "Ethernet 0" interface on the back of the 887v.
I'll test this as soon as possible. But, I'm still looking forward to the fix for this Bug ID.
Which version of IOS software are you running today on your 887 ?
Let me try to reach out some contacts to get an answer for you.
I just checked, with TAC, about this bug 'being fixed'. I was told that it has been fixed in some 15.xT versions. But those versions have not been released, yet, because they are still being tested.
Do you know of a particular version that has been tested and is released?
This post looks like it's out of order (I posted it Friday at 10:56 a.m.) Sorry for any confusion.
I reached out to the engineer who worked on this platform & the bug. He recommend that you can use one of the 15.1T images for your 887v router that should have a fix for "CSCsr27209".
When i asked for a specific version he confirmed that "15.1(2)T1" should help you.
Can you please try this image and let me know if it helps ?
Chirs and Arun hi
I have the same problem that Chris have with his 887V router.
I already tried the following IOS:
None of these IOS solve the problem and I can't get the ATM0 interface
Arun, can you check again with the engineer what is the IOS that solve this problem (if there is an IOS that solve the problem)
Chirs you mention before that:
"The engineer that owns my case gave me a work around using the 'ethernet 0' interface in place of the ATM interface.” can you tell me what was the work around you did.
For VDSL mode (vdsl2), Ethernet Packet Transport Mode (PTM) is applied. So you’ll see interface e0 instead.
For ADSL/ADSL2+, etc, you will see interface a0 as the line.
Please refer to "DSL Specification" at this place : http://www.cisco.com/en/US/prod/collateral/routers/ps380/data_sheet_c78_459542.html
From what that I understand from the "Cisco 880VA - DATA SHEETS" and from the "Cisco 880VA - Q&A" that found in these links
The Cisco 887V supposed to support ADSL2/ADSL2+ & VDSL2 Automatic.
Also in the "Cisco 860,880 and 890 Configuration Guide", it says that Cisco 887V can be setup to connect to the ADSL via the ATM0 interface. As you can see in the example over here:
But none of that really happened.
It seems that there is a fundamental bug with these devices that make it impossible to connect to the ADSL2 / ADSL2+ via the VDSL2 controller.
I see couple of things in your latest post.
1) In one of the original message, you have referred to a 887v router. But in the latest datasheets & configuration examples you are referring to 887va models.
2) Just to make sure
I'm sorry for the much delayed response. This project has been pushed down on my list of priorities so I haven't been able to give it much attention. But, I just recently learned that AT&T uses 802.1x authentication with a 2Wire 3800 modem for their Uverse activations. I haven't learned the exact workflow of the authentication and line provisioning procedure, but I that's enough to know that the MAC address of my 887v router will not authenticate with AT&T's radius server. So that makes 'upgrading the code' on the router a mute point now. I had the router in place and was ready to test, but I guess It was all in vain.
It would really be nice if AT&T would allow the use of the 887v router. Then we could continue to deploy CVO solutions like we've been deploying with ADSL using 887 routers.
Thanks for your help.
Mac addresses are configurable. Just clone the address of the AT&T provided device.
How is that that you learned that "that the MAC address of my 887v router will not authenticate with AT&T's radius server"?
Cisco had a great interest in ensuring that CVO works with all services, and I am shocked to hear this assertion.
Are you already working with the TAC? There are several DMVPN experts who have contacts at AT&T...
An AT&T representative gave us that information which I believe he learned from a level 3 engineer.
Originally I was told that an AT&T service technician stated it will never work, but did not give an exact reason why. So, having Uverse installed at a location for testing purposes, we connected an 887v router to the 2wire modem and formed a VPN tunnel (using a pass through method). Then I prepared to test authentication through the VDSL controller on the 887v. That's when I could not configure the ATM interface and discovered the bug. I have had a TAC case open for some time now but we have had limited access to this router and I was told we were also looking for some support from AT&T. We did hear back from AT&T, and that was the final determination.
I did some looking and found this is not a new issue. It has been discussed by AT&T technicians in a forum that dates back to last year at DSLReports.com http://www.dslreports.com/forum/r22423850-Using-a-3rd-party-VDSL-modem
The forum is 5 pages long and details serveral attempts to work around the problem. But I don't think anyone ever had any luck.
I'm still hoping that there is a way to do this. All of our CVO or ECT deployments are configured for ADSL2 so that we can manage and monitor the connection with the carrier. This also a provides us better security by cutting out the modem and the possiblity of someone connecting another router, hub, or switch between our Cisco router and the Carrier.
I just wanted to mention that this issue is somewhat tangential to DMVPN/CVO. You can
put the DMVPN router behind the AT&T modem and it should work fine.
BUT, I also highly agree with Chris Ingram, in that I do think in many cases it is much better
to be able to place the DMVPN router directly connected to the ISP link. Less boxes to deal
with and you are also assured that you don't have a box between the DMVPN router and the
ISP link that may mess up the DMVPN tunnels.