Join Director of Product Management Todd OBoyle on April 26th as he covers the key elements of a phishing protection program. Whether you’re an old hat at phishing education or considering starting a program -- we'll discuss critical components that should be in any program.
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.
Who is Participating?
Hi
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(.
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(.
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.
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(
Here is something to check. Sounds like either a router or trunking issue.
Router on a stick could be done 2 ways, both using subinterfaces, and might be worth changing to see if it helps
1. you use the physical interface for the default vlan and use the subinterfaces for all other vlans
2. do not give the physical interface an ip and create subinterfaces for all vlans.
use the encapsulation dot1q 1 native command on the default vlan assuming you kep it on vlan 1
depending on IOS the way you set this up is different.
http://www.cisco.com/en/US/tech/tk389/tk815/technologies_configuration_example09186a00800949fd.shtml
When you say that you can ping the vlan you are only pinging the switch here, the vlan interface. But you are using a seperate router (Router on a stick) so not being able to ping the connected interface seems like a trunking iissue. I would start by verifing that your trunks are working
show interface trunk.
If you post problem connections( the switch and the router running configs) a more substantial
Again, I would suspect the trunk connections first and the router setup second (this is part of the trunk of course).
Router on a stick could be done 2 ways, both using subinterfaces, and might be worth changing to see if it helps
1. you use the physical interface for the default vlan and use the subinterfaces for all other vlans
2. do not give the physical interface an ip and create subinterfaces for all vlans.
use the encapsulation dot1q 1 native command on the default vlan assuming you kep it on vlan 1
depending on IOS the way you set this up is different.
http://www.cisco.com/en/US/tech/tk389/tk815/technologies_configuration_example09186a00800949fd.shtml
When you say that you can ping the vlan you are only pinging the switch here, the vlan interface. But you are using a seperate router (Router on a stick) so not being able to ping the connected interface seems like a trunking iissue. I would start by verifing that your trunks are working
show interface trunk.
If you post problem connections( the switch and the router running configs) a more substantial
Again, I would suspect the trunk connections first and the router setup second (this is part of the trunk of course).
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.
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
All Courses
From novice to tech pro — start learning today.
-
Course of the Month10 days, 12 hours left to enrollMonitoring and Operating a Private Cloud with System Center 2012 R2 273 lessons
Another thing you could do is run Wireshark or Sniffer and see what is happeneing when you ping from a PC at one site and it works but another PC at another site doesn't work.