04-02-2019 02:20 PM
I am trying to configure a 3825 router and a 3G HWIC, with the gi0/0 WAN interface as primary and the cell0/2/0 as secondary. The gi0/1 interface is subdivided into approximately 10 sub-interfaces.
The primary interface works fine, and when the cellular interface takes over, it also works fine. The issue comes when the primary interface comes back online. For whatever reason, the primary interface does not route, and the internet drops.
I suspect I have something wrong in the routing table or the NAT.
Any help is GREATLY appreciated!
04-03-2019 10:04 AM
I have several comments about this configuration.
1) you have configured backup delay for the backup interface so after G0/0 becomes available it will wait for 30 seconds before it starts to route. Is it possible that your observation that the Internet fails is due to that delay? If you wait for a minute does Internet start to work again?
2) you nat traffic to the Internet with one address when using G0/0 and with a different address when using cellular. Is it possible that as you attempt to come back to G0/0 that there are still translate entries in the translation table with the cellular address? Would clearing the translate table make Internet work?
3) You are using the feature of backup interface to have traffic fail over. In my experience with backup interface the two interfaces typically use the same IP address. But G0/0 and the cellular are both configured for dhcp. So they are using different addresses. Not sure if there is any impact from that.
4) you have 4 interfaces configured to use dhcp. So there are potentially 4 interfaces learning a default route. Additionally you have multiple static default routes as backup (with higher AD). So it is not clear which default route you are using at a particular time. I wonder if the problem with Internet access when reverting from cellular to G0/0 may be related to changing the routing table? It might be helpful to see the output of show ip route from a time when you are on G0/0 and from a time when you are on cellular, and at the time when you are attempting to revert and the Internet is not working.
5) You have backup static routes configured with next hop addresses of 192.168.0.1, 192.168.5.1, and 192.168.6.1. Those subnets do not appear in your configuration. Are these perhaps subnets that you are learning via dhcp?
6) you use access list 1 as your dialer list (which is common). You also use acl 1 to control address translation for the cellular interface. Since acl 1 does permit any, it is difficult to see how the other translations specified would ever get any matches.
7) In my experience when doing address translation on several outbound interfaces it is common to control the nat with a route map, where the route map can match on both the outbound interface and on the acl. Since each of your translation configurations has a unique combination of interface and acl it may be working ok. But it would be a more conventional config if they used route maps.
I am not which which of these, if any, explain your issue with reverting to G0/0 but are all things that you might consider.
04-03-2019 10:38 AM
Thanks for the reply. As you have no doubt gathered, I am in a very steep learning curve here. I am studying for my CCNA, and at the same time, as Captain of the vessel, and the guy with the most IT knowledge I am setting up the vessel. So, perhaps a bit of background would help. (And my thought (?) processes)
The ship has three ways to connect to the internet via the 3825, which, hopefully, will soon be replaced with a 3925/45.
(Can't afford the newest gear yet, unfortunately)
1 is when in port we connect via a cable modem to the 3925. That is the Gi0/0 interface which receives an ip address, via DHCP, from the modem. (I suppose I could use a static IP here?) The Gi0/1.xx is for the inside VLans for the scientists / surveyors, or other charterers.
Cellular 0/2/0 is being tested to see if it is more effective to communicate, up to say 50 nautical miles offshore, than running it through interfaces Gi0/1/0 which connects to a port on our V-Sat that is configured as a DHCP server (192.168.5.0 network) by KVH, the Satellite service provider. Gi0/3/0 is also on another port on the KVH which provides DHCP on the 192.168.6.0 network. This network requires that the user connect to the server running ashore, provide a username and password, and then they get passed to the internet. It is not ideal, but eventually I hope to see the KVH system replaced with a more "User configurable" system.
So, I have bitten off a rather large mouthful. Everything internal to the ship is working fine. The Gi0/0 interface works fine. The cellular interface works when it is not being used as a backup. The other two interfaces I have yet to figure out how to fail over to when we pull the plug on the cable internet connection, and the GSM signal drops. I may have to do this manually(?).
OK, that will give you a bit of the background.
I will have to go and read up on the use of route maps. I have seen it mentioned, somewhere, before. If it will simply that "mess" of a config file, I am all for it!
Hope you don't mind me picking your brain, as I have been getting just a tad frustrated the last few days. LOL!
One other thing, I can't seem to get SSH to work properly on the router. If you could have a peek at the config file and see if I am missing something, that would be really helpful. When I run Putty as an SSH client it gives me a password error, if I recall correctly.
04-03-2019 03:04 PM
I am happy to provide some guidance for you. First let us address the issue about ssh access. Can you post the output of show ip ssh? This will verify whether ssh is enabled and running. From the fact that you describe the error as a password failure I believe that it probably is running. But lets be sure about it. Assuming that it is running the most probably issue is that you are not using exactly the ID and password that were configured. So my advice is to reconfigure the ID and password (or perhaps to configure a new ID and password). Then try ssh with the corrected/new ID and password.
As far as address translation is concerned I will make a few suggestions.
1) Configuring nat needs an access list to identify the traffic to be translated. In the current config you have a unique access list per interface. That is fine, but is not required. So you need to tell me whether you want to keep a unique access list per interface or to use a single access list for all interfaces. (I frankly do not see much advantage for you in maintaining separate access lists, but it is your choice).
2) The access lists that you currently use for nat are not consistent. You are using access list 1 and I have commented that this needs to change. You are also using access lists 10, 20, and 30. They are mostly the same but not quite the same. Access list 10 include a permit for 192.168.1.0 while access lists 20 and 30 do not include this network I suspect that was not intentional. Depending on your answer to 1) this may be a moot point.
3) the address translation might look something like this
access-list 10 permit 192.168.1.0 0.0.0.255
access-list 10 permit 192.168.10.0 0.0.0.255
access-list 10 permit 192.168.20.0 0.0.0.255
access-list 10 permit 192.168.30.0 0.0.0.255
access-list 10 permit 192.168.40.0 0.0.0.255
access-list 10 permit 192.168.50.0 0.0.0.255
access-list 10 permit 192.168.60.0 0.0.0.255
access-list 10 permit 192.168.65.0 0.0.0.255
access-list 10 permit 192.168.70.0 0.0.0.255
access-list 10 permit 192.168.75.0 0.0.0.255
access-list 10 permit 192.168.150.0 0.0.0.255
route-map nat_cellular permit 10
match ip address 10
match interface celleular0/0
ip nat inside source route-map nat_cellular interface cellular0/0 overload
and you would have similar logic for the other interfaces.
04-04-2019 02:54 PM
I have been thinking some more about your questions and have some further suggestions. You describe it as
The ship has three ways to connect to the internet via the 3825
As you introduce the HWIC does it not really become four ways to connect?
I am wondering about the use of backup interface. This is intended to implement that the backup interface is dedicated to backing up the primary interface. But as I read your description I believe that you really want to use it in situations where you are not docked and are within 50 miles of shore. And where it might be an alternative to satellite transmission. For that case it seems to me that it is better to treat cellular as a fourth method on its own rather than as just a backup to the cable modem.
I believe that this is an intriguing issue to resolve. You have 4 methods of access and you want to choose which method to use based on parameters which can not be programmed into the IP routing table (are you at dock, are you not at dock but within 50 miles of shore, are you more than 50 miles from shore). There is a manual solution which would work: shut down interfaces that are not appropriate for the current environment and no shut the interface(s) that are appropriate for that environment. It would be nice to find a solution that automated that choice. But given that the parameters that govern that choice are not related to network functions, I do not know how to create an automated solution.
04-05-2019 07:25 PM
Apologize for the delay but we had our internet line from the pole to the distribution unit go down. (My luck!)
Ok, I managed to get SSH working. I was using the incorrect IP address. I also changed Gi0/0 from DHCP to static and that made a few things easier.
I have re-written the config file and I will have to copy it and bring it home and send it to you.
Yes, it was, and is, a head scratcher for me as well. You are probably right bout doing all this manually, but I hope not, as I can find my way around a router and switch, but most ship's officers don't, and that creates a problem, as you can imagine.
I also cleaned up the config file, per your suggestions.
I will bring the file home tomorrow as well as the "show IP route" for each of the interfaces.
04-06-2019 01:52 PM
Thanks for the update. Glad to know that you got SSH to work. Changing G0/0 from DHCP to static does simplify some things. But I wonder about how it will work as your ship moves from port to port. When you dock in a new port does the address used change, or does it stay the same? Don't know how your cable modem is set up - can you clarify?
I look forward to seeing the updated config, and to trying to figure out the several challenging aspects of what you want to accomplish.
04-16-2019 08:49 AM
My apologies for the delay. We have had serious internet issues on shore and then we went out on a job. However, back alongside and internet issues with the provider have been ironed out, at least temporarily!
OK, I have attached the new config. I had it working with a static IP on the gi0/0 and then we started having issues and I thought it might be the configuration. So I changed it back to DHCP. However, it ended up being issues with the ISP. I will probably change it back to a static address via the ISP's modem.
I will let you have a look at the config file. By the way, the GSM worked fine alongside. Now waiting to see what the owners want to do with regard to a booster and upgrading to a 3925/45 and a 4G modem, or stay with the 3G for now and do more testing.
P.S. Can we use administrative distance to differentiate between the interfaces?
04-22-2019 08:17 AM
Thanks for posting the updated config. I have these comments about it:
- I notice that you have removed the backup delay parameters. Has that improved the original issue about failing back from the cellular interface to the Gig0/0?
- the configuration of address translation is much better. I do have a question about it. We are including 192.168.150.0 as addresses to be translated and I had included it in my original suggestion. But in looking at the config I realize that this is for VOIP, and I wonder if you do want to translate that traffic. I do not know what you are doing with VOIP and so am uncertain whether it should be translated or not.
- I notice that there are not DHCP scopes for 192.168.50.0 or for 192.168.70.0. Is this intentional? Will devices in these subnets be manually configured?
- you had asked about the dialer list in the config. I am not clear whether it is needed or not. It is a normal part of configuring use of interface dialer 1. I am not clear whether your cellular is using the interface dialer 1. And since the config is a bit incomplete and the interface is shut down then I assume that you are not using it. If you are using it then one issue is that it is attempting to use access list 1 to identify traffic to use the dialer and that access list does not exist.
There are several comments about routing in your config and they are somewhat interconnected.
- use of DHCP frequently includes supplying a default router (default gateway) for the clients in the scope. Do the scopes for DHCP for your outbound interfaces (Gig0/0, Gig0/1/0, Gig0/3/0, cellular) include a default gateway?
- You have configured 4 static default routes. Originally several of them included Administrative Distance to define a primary default route and backup default routes. Now all the static default routes have the default AD. On the surface it seems to present a question about which one would be used if multiple routes are configured. The output of show ip route makes it clear that only 1 of the configured static default routes is being used (the one on Gig0/0). The reason for this is that the interfaces associated with the other default routes are not in the up/up state. So perhaps this illustrates a way to select which route to use.
- If the DHCP scopes for your outbound interfaces do include a default gateway, then the configured static routes are not needed and can be removed. And then the choice of which default route to use will be determined by which outbound interfaces have received their IP address and gateway information.
- We had discussed whether using static IP on Gig0/0 might simplify the configuration. In this context it would be better to keep Gig0/0 as DHCP.
- I am not clear about how you would use Gig0/1/0 and Gig0/3/0. Would you use one at a time or both at the same time. If using both then there might be 2 default routes in the routing table and there might be load sharing/load balancing of your outbound traffic.
04-24-2019 01:11 PM
Yes, the cellular interface does seem to work better without the delay. I have the three interfaces (0/1/0, 0/3/0, and cellular0/2/0 all shutdown at the moment as we are still having problems with the internet line to the vessel and I don't want to rack up unnecessary charges on these interfaces. Unfortunately, cellular comms are not as cheap in Canada as south of the border, and unlimited internet plans are scarce as hen's teeth up in my neck of the woods. (read non-existent)
The 50.0 and 70.0 subnets were just missed in the configuration and I have remedied that oversight.
Each DHCP pool contains a default router, but I don't think this is what you are getting at. Should each external interface have a default router associated with it?
I had removed the administrative distance to basically simplify the configuration, but I will reinstate it for now to differentiate between the interfaces when they are all up. (At sea, where gi0/0 will be disconnected)
I am afraid you lost me with regard to removing the static routes if there is a default router specified. Do you mind showing me an example, or pointing me to a document that would demonstrate this?
Look forward to your next.
04-24-2019 03:40 PM
It is interesting that removing the delay makes the backup interface work better. Glad we caught the need for DHCP scopes for the 2 subnets.
There are 2 types of DHCP in your config. So I need to be more careful to avoid ambiguity. You have DHCP scopes for the subnets in your local network and those scopes include specification of a default router (as they should). This is not what I was talking about. You also have DHCP for your Gig0/0, Gig0/1/0, and Gig0/3/0. And while technically your cellular does not use DHCP what it does with PPP address negotiated is so similar that we might as well include it with the other outward facing interfaces. This is the DHCP that I was talking about.
Let me try to explain what I was talking about from a somewhat different perspective. Perhaps it will be easier to understand. It has to do with routing and how your router will decide how to forward traffic. Forwarding traffic from outside to your local subnets (or forwarding traffic between your local subnets) is easy because the local subnets are automatically in your routing table. The challenge is about how to route traffic from inside going outside. You potentially have 4 choices of how to route outbound traffic. So how would your router decide which one to use?
Right now you have 4 static default routes and they are all equally attractive. By default your router would try to use all of them. You could add the Administrative Distance parameter to your static default routes to establish an order of preference. But that still is not very satisfactory. So maybe there is some alternative about how to have default routes other than to manually configure static default routes. That is when I started thinking about DHCP learned routes.
When your Gig0/0 learns its IP address from DHCP does it also learn a default route? It it is up and the other 3 are not up then there is only a single default route and the choice of correct route is easy. If Gig0/0 is not working (and therefore has not learned a default route from its DHCP) then cellular should be used. If the router learns a default route from the PPP negotiation then there is only a single default route and the choice of correct route is easy. If both Gig0/0 and cellular are down then Gig0/1/0 or Gig0/3/0 might be up. If your router has learned a default route from the DHCP negotiation then the choice of correct route to use is easy.
This approach assumes that each of the public facing DHCP negotiations will include a default route. If it turns out that any of your public facing DHCP negotiations does not include a default route then we have a problem and will need to figure out a solution. But the first step is to verify whether each of your DHCP negotiations does include a default route. To test this I suggest that you remove all of the currently configured static default routes. Then bring up the first interface. Let it negotiate and let things settle down. Then do show ip route. Look to see if there is a default route. Then shut down that interface and bring up the next interface. repeat the process for each of the interfaces.
04-26-2019 05:20 AM
Seems there is another issue that is impacting the problem. The two interfaces that connect the V-Sat to the router are HWIC-Ge1-SFP modules and they do not appear to be properly communicating. I have a couple of other things to check, and then I will get back to you.
04-26-2019 06:13 AM
Sorry to hear that the interfaces for V-sat are not working. Good luck with troubleshooting them. Let me know as you make progress.
04-26-2019 07:45 AM
Can you have a look at the attached files? The VSat works if I plug in direct with a laptop. However, when I try to use the HWIC-GE1-SFP interface with a copper SFP (Cisco SFP) I get zilch. The interface shows up/up, and I have checked all the cables for any issues there and they all come back as ok. They are all Cat-6a shielded cables.
I am kind of scratching my head here. LOL!
04-26-2019 08:28 AM
When you connect with the laptop what is the speed of the laptop interface?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: