Problem with Router on a stick using port channel for logical interfaces
Hello all
Well, I'm running against a brick wall with some config issues. We have several sites that have ROAS systems using port channels that we want to connect to other switches to extend the network. We are using broadband radio links to connect sites via dot1q trunks, all switches and routers have identical configurations, IP addressing notwithstanding. Some sites have worked fine and some have not worked at all, so much so that clients cannot even ping a directly connect interface on the router but can ping the default gateway for the VLAN on the same router.
Well, I'm running against a brick wall with some config issues. We have several sites that have ROAS systems using port channels that we want to connect to other switches to extend the network. We are using broadband radio links to connect sites via dot1q trunks, all switches and routers have identical configurations, IP addressing notwithstanding. Some sites have worked fine and some have not worked at all, so much so that clients cannot even ping a directly connect interface on the router but can ping the default gateway for the VLAN on the same router.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
It sounds like something has a routing issue maybe due to an incorrect subnet mask or soemthing like that. Possibly traceroute would point you in the right direction by showing where it is dying. Maybe try it from both sides.
ASKER
Hi
Tried that to. If for example I do extended ping and trace using the source interface as the WAN (ip nat outside) interface to the host on the second inline device it fails. If I do just a default (so source address would be the sub interface on the port-channel I believe) it's fine :0(. Same same from host to WAN interface and thus the reason NAT is failing from hosts on this second inline device (I am assuming). This problem is common to sites that do not function. I've checked all mask's being issued from DHCP and the NAT ACL and all are correct, as I say any host connected to the first switch at the problematic sites has no problems at all which I find the most puzzling as I would have expected those to fail as well :0(
Tried that to. If for example I do extended ping and trace using the source interface as the WAN (ip nat outside) interface to the host on the second inline device it fails. If I do just a default (so source address would be the sub interface on the port-channel I believe) it's fine :0(. Same same from host to WAN interface and thus the reason NAT is failing from hosts on this second inline device (I am assuming). This problem is common to sites that do not function. I've checked all mask's being issued from DHCP and the NAT ACL and all are correct, as I say any host connected to the first switch at the problematic sites has no problems at all which I find the most puzzling as I would have expected those to fail as well :0(
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi
Already done all of that as well. All VLANS are being trunked, also sh ip cef also confirms clean layer two connectivity.
I have however been able to isolate this a little more; it appears that the broadband radio links we have between sites and configured to act as a simple bridge are not doing so (the price you pay for not buying quality equipment I guess). We know this a source MAC is being stripped and replaced with the MAC of the radio link.
The sites we have working can all see the default gateway genuine MAC address in the mac table and the ones that don't see the radio interface mac adddress.
I've got engineers out today changing the configuration on this 'bridges' to hopefully put this to bed.
Thanks for all your comments, I'll post the conclusion of todays adventures later.
Already done all of that as well. All VLANS are being trunked, also sh ip cef also confirms clean layer two connectivity.
I have however been able to isolate this a little more; it appears that the broadband radio links we have between sites and configured to act as a simple bridge are not doing so (the price you pay for not buying quality equipment I guess). We know this a source MAC is being stripped and replaced with the MAC of the radio link.
The sites we have working can all see the default gateway genuine MAC address in the mac table and the ones that don't see the radio interface mac adddress.
I've got engineers out today changing the configuration on this 'bridges' to hopefully put this to bed.
Thanks for all your comments, I'll post the conclusion of todays adventures later.
ASKER
Ok guys. Problem solved. I guess you could say it was a sort of routing issue. Wireless bridges had been deployed in different modes (Station and access point) at different locations.
Thanks for all your comments, they certainly added to the thought process.
Thanks for all your comments, they certainly added to the thought process.
ASKER
Although neither answer was the complete solution they did set my thought process working.
ASKER
I haven't as yet gone down the packet sniffer route but I'm just running some low level NAT debugs and I cannot even see packets from a PC on one of the switches being NAT'ed.
Basically I have the ROAS (with a Port-channel as the sub-interfaces) which is connected over a dot1q trunk to a switch. Host connected to the first switch have no problems with Internet traffic and or other traffic. I then have another (second) switch connected, again over a dot1q trunk, which host cannot access the Internet from. They receive DHCP from the router without any problem, they can ping all the sub interface IP's on the port-channel group and even ping pc's on the first switch in the same VLAN but cannot ping anything on the management VLAN of another switch. As I say they are not appearing in any nat debugs so it appears there is some kind of issue in the way the port-channel is configured. That said I have EXACTLY the same configuration (one router, multiple switches connected to each other) and it works just fine. A case of not seeing the wood for the trees I think :0(.