[nsp] DSL customer reachability issues

Streiner, Justin streiner at stargate.net
Wed Jul 2 13:39:51 EDT 2003


This may also be subtitled: "I may be an idiot" ;-)

I have DSL service from several DLECs coming into one of my facilities.
Most are delivered via ATM.  One such provider hands me an ATM DS3 and
builds one PVC per customer serving area, e.g. customers served out of the
same geographic area would be aggregated onto the same PVC.  The
architecture is bridged and we're running RBE on our side.  Sub-interfaces
are created on our side for each PVC, e.g. ATM0/0/0.223 and that interface
has a chunk of IP space (some public, some not) configured on it.  A modem
at the customer's premise converts the DSL traffic into Ethernet frames.
The customer gets an IP address from the network(s) assigned to whatever
PVC they're riding in on.

It's not the cleanest architecture, but we're bound at least for now by
the telco's architecture and our own legacy architecture decisions.

I have an issue with one customer in particular who has a Cisco 3640 on
the end of their DSL circuit to us, for use as a backup in case their T1
fails.  With all access-lists removed on both sides, I cannot ping
(from my router directly upstream of them) the customer's outside Ethernet
interface that's attached to their DSL modem.  The MAC address I see in my
ARP table is the same as the MAC address on their Ethernet interface.  Not
being able to see the customer's router is making troubleshooting another
problem much more difficult.

The T1 is to another provider and the customer is running BGP with us and
the other provider.  At this point we're just sending them a default
route, but just doing a ping from my router to his

The odd things are:
1) I can reach other customers just fine, including other customers that
	are aggregated to me over the same PVC as this problem customer.
2) The customer can reach my router with no problems.
3) I can reach devices beyond the customer's router without problems.

Any other ideas on things I should look at in troubleshooting this?  Since
the customer's interface is directly connected in this case, where the BGP
default route points should be irrelevant at this point...

jms


More information about the cisco-nsp mailing list