what you could do, and the only way to prove what is happening, is to do
the following
7200 -- atm sniffer -- DSL -- CPE -- sniffer -- linux box
run
debug atm packet interfact <intf> <vpi/vci>
on the 7200, and ping the linux box.
then on the sniff the line.
we need to see what is happening to the arp request and response.
you could be running into a
(a) bug on 7200
(b) bug on the cpe
(c) pattern sensitivity on the line, which causes the packet to be lost
i would suggest opening a case with the TAC, you should be able to get
a CE to help you read thru' the hex dump of the debug atm packet and
figure out what is going on. but if the packet dump on the router is good,
the only way to narrow this problem down is to get sniffers in the above
locations.
cheers
.siva
>
>
> > is your DSL provider BA?
> nope
>
>
> > 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.
>
> Yeah, my thinking was that they were blocking the broadcast address
> at least- but they swear that they have no layer 2 filters at all.
>
>
> > 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.
>
> I have been reading about it- I may give up on IRB and go that route;
> but again feel that there is something specifically wrong since the
> CLEC has said that others are using IRB on a 7206.
>
> Thanks much,
> mm
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:16 EDT