[c-nsp] IPv6 ND and ATM internetworking

Charles Sprickman spork at bway.net
Tue Sep 17 23:36:17 EDT 2013


This is kind of a long shot since a large part of the network in question is not under my control, but I'm hoping I can get a little input that can give me a direction to go in here.

We have a number of DSL customers that come in from a wholesaler.  The setup basically looks like this:

Our router --- GigE  --- VLAN --- (wholesale network) --- Customer CPE

To the best of my knowledge, the wholesale provider's network looks basically like this:

                       /--- GigE --- metro-e and EoC services --- end users  (all ethernet network)
US --- GigE --- ASR9K /
                      \
                       \--- ATM switch --- DSLAM in CO --- DSL --- end user CPE (legacy ATM network)

We get one VLAN on a GigE interface for each customer, regardless of whether they are on the legacy ATM network, on the metro ethernet network, or on the "Ethernet over Copper" network (basically DSL without the crap ATM layer).

I have no IPv6 issues with the native ethernet stuff, that just works.

On the legacy ATM network, I have a few people reporting a bit of packet loss after they have not generated any IPv6 traffic.  The first few pings will time out, and then everything is fine.  It sounds like something in the ND process is failing, most likely at the ATM to ethernet translation layer.  I'm double-checking this, but from what I have heard from the customers, their router shows no IPv6 neighbors for a few seconds after starting an IPv6 ping.

I'm hoping someone here has some knowledge of what might be going on in the translation, and whether some ND timeouts might be altered on my side and the customer's side (many are using Cisco 837 units with ADSL WIC cards, so they can do considerable tweaking).

One small hint for someone who's seen this sort of config is this snippet that's exposed in the wholesaler's OSS interface: NYCMNY83-C-ASR1.Bundle-Ether1051.4307/307:ETH - that's what we see as the circuit endpoint.  The "307" corresponds to the VLAN on our side of the GigE handoff.  The "1051" and "4307" don't correlate with anything we know about the customer (dslam port, shelf, etc.).  We have an option of setting the DSL line encapsulation to either RFC1483 "bridged" or "routed", and we  know that IPv6 only works over this setup when we have the encapsulation set to "bridged", which sort of makes sense to me.

Each customer has a subinterface on our end, it's basically this:

!
interface GigabitEthernet0/2.307
 encapsulation dot1Q 307
 ip unnumbered Loopback4 (for IPv4, we point a static /32 at the interface out of the same subnet as lo4)
 ipv6 address 2607:D300:X:X/126
!

No PPPoE, no DHCP on v4 or v6.

I know this is short on information, but IPv6 is not at all on the roadmap for this wholesaler, so we're hoping that the bridged setup should allow us to work around this.  For starters, since I'm relatively new to IPv6 on anything beyond a local LAN setup, any suggestions on what information to gather from both ends (again, I do have Cisco gear on both ends).

Thanks for your time,

Charles



More information about the cisco-nsp mailing list