Re: [nsp] Bridging DSL to 7206

From: Siva Valliappan (svalliap@cisco.com)
Date: Fri Sep 08 2000 - 17:24:29 EDT


is your DSL provider BA? BA uses mac filters and blocks mac addresses.
you will need to contact the relevant DSL circuit providers to open up the
appropriate MAC filters. then hard code the mac address on your BVI
interface. otherwise everytime the router reboots, it will calculate a
new MAC address for the BVI interface. it is possible other DSL
service providers are using similar MAC filters as well.

i would strongly recommend reading thru' the RBE - route bridge encapsulation
feature. this is an improved aggregation feature for 1483 bridged
traffic. it's supported from 12.0(5)DC on the 6400, and 12.1(2)T on some
IOS platforms [including the 7200]. we also support RBE with
un-numbered DHCP support from 12.1(1)DC and 12.1(2)T onwards.

since each PVC now becomes a routed inteface, you have all the normal
features you would expect from a l3 interface, as opposed to a l2 interface
when doing IRB....

cheers
.siva

>
> I've been tearing out some small amount of remaining hair here and
> wonder if anyone has some thoughts...
>
> Using a 7206 and a PA-A3-T3 to terminate a backhaul DS3 loop from a
> CLEC who is providing DSL connections. The 7206 is running
> 12.1(1a)T1. The relevant config is:
>
> bridge irb
> !
> interface ATM2/0.15 multipoint
> description PVC to CLEC
> pvc clec 15/799
> encapsulation aal5snap
> !
> bridge-group 20
> bridge-group 20 spanning disabled # or not, have tried both
> bridge-group 20 subscriber-loop-control # or not, have tried both
> !
> interface BVI20
> description CLEC DSL customer group
> ip address A.B.C.1 255.255.254.0 # a /23 ... have also tried a /24
> ip helper-address D.E.F.G
> ip route-cache same-interface # or not
> no ip mroute-cache
> exit
> !
> bridge 20 protocol ieee
> bridge 20 subscriber-policy 20 # or not
> bridge 20 route ip
> !
> end
>
>
> We've installed a DSL line and are testing it; we've had various
> systems and operating systems on it. A good description of the problem
> can be had with our experience with a linux box on the end of the
> DSL line.
>
> As a first step, I hardwire an IP address on the linux box.
>
> If I try to ping the router (at the other end of the DSL line) from
> the linux box, it fails. However the linux box *does* gain the ARP
> address for that router, meaning that it does get the MAC level address
> from the link. (I can also see the arp request and response via tcpdump.)
>
> If I try to ping the linux box from the router, there is no response,
> and the cisco does NOT obtain the arp address from the linux box. I
> can see the cisco sending ARP queries in order to obtain the MAC level
> address for the linux box. The tcpdump on the linux box does NOT show
> any arp queries arriving.
>
> If I go to the cisco and hardwire the arp info for the linux box's IP
> address, I now have connectivity. I can ping between the router and
> the linux box, and indeed out to the rest of the world from the linux
> box.
>
> If I attempt to make DHCP requests from the linux box, they never arrive
> at the cisco (at least not in any way that I can find -- they don't
> show up in packet log, and the packet counts do not go up, nor are they
> forwarded to the helper address).
>
> Using tcpdump on the linux box, I can see the DHCP requests going out the
> ethernet interface, and nothing coming back.
>
> It almost looks like the CLEC is blocking layer 2 broadcast traffic,
> but (a) they say they are not and (b) they have other customers. So
> I'm inclined to believe I've done something wrong. I've read
> documentation until the pixels are wearing off onto my eyeballs, and
> have tried an enormous amount of tweaks.
>
> Any clues?
>
> -mm-
>
> --
> Mark E. Mallett | http://www.mv.com/users/mem/
> MV Communications, Inc. | http://www.mv.com/
> NH Internet Access since 1991 | (603) 629-0000 / FAX: 629-0049
>



This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:16 EDT