MA5600T----MA5603T----ADSL mode (PPPoA)
all PPPoA users are under MA5603T can not dial anymore, but PPPoE users are working well.
1.After changing the role of uplink-port on MA5600T by using command “network-role 0 cascade”, this problem solved.
2. by default the role of uplink-port is “uplink”, it’s necessary to modify to “cascade” when this port need to be put into cascade circumstance.
3.on V800R007C00SPC306, This problem caused by implement-mechanism, as the uplink-port isn’t set to cascade role, moreover there are a lot of PPPoA subscribers are running on the MxU or MA5603T which cascaded with MA5600T. These PPPoA packets are converted into PPPoE by MA5603T would be captured up onto CPU of MA5600T, afterward MA5600T would discard them directly because of no match entries. This problem has nothing to impact PPPoE subscribers.
1.Making capture between MA5603T, we can apparently discover PADI packets came from MA5603T, whereas we can not find PADI packets go out from uplink-port of MA5600T, which stand for that MA5600T discard those PADI packets with some reason.
2.Attempting to disable PPPoA MA5600T, afterwards we can see those PADI packets which were discarded by MA5600T forward to uplayer correctly, in the mean time, those PPPoA user under MA5603T can make dial successfully. But the PPPoA user under MA5600T are aborted.
3.Modifying pppoa mac-pool on MA5603T and MA5600T, to make both mac-pool not overlap, and then enable pppoa on MA5600T, the result is the same, PPPoA users under MA5603T still can not dial.
4.From now on, in this cascaded topology, we can reach a conclusion, those PPPoA packets has been converted into PPPoE packets by MA5603T that would be grabbed up onto CPU of MA5600T, and then MA5600T will discard them because of no matched entries.