You can do this directly with the NV1335 if you want. I'm not sure why you would even need the 3140. Or you could use a trunk between the 3140 and the 1335, assign a VLAN to each subnet over the trunk, and use the 1335 to distribute the VLANs as layer 2 to access ports.
The reason we were using the 3140 was primarily due to recommendation by Adtran sales. I know there was an initial discussion of double duty as an SBC which we currently are not going to attempt. Maybe that's why the recommendation. (There may have also been a concern about throughput.)
At any rate, regarding using a trunk between the two: I'll give this a try but after doing some digging, I'm not finding a lot of information on this subject, so hope you don't mind a few more questions.
- I assume trunk settings are all on the 1335? I would just configure the appropriate switchport to trunk? (If there are example configs or documentation out there that I just didn't find, I'm happy to peruse them.)
- On the 1335, for the remaining config I'm a bit confused. Do I need to set up VLANs corresponding to the ones on the 3140 and then assign them to specific switchports?
I'm continuing to plug away at this and have found this document: Configuring InterVLAN Routing in AOS - Quick Configuration Guide. Hopefully, that will provide enough information to answer those two questions.
FYI, we've opened a support case with Adtran. No resolution yet, but here's the information about a comparison of using the two routers in this instance. I thought it might be useful to include here. This info is from Jordan with Adtran:
Per our feature matrix (https://supportforums.adtran.com/docs/DOC-1115), there is a significant difference in the throughput between a 1335 and a 3140. With just the firewall turned on, the 3140 can handle 600 Mb/s aggregate throughput while the 1335 can only handle 75 Mb/s. When using QoS/traffic shaping, the 3140 can handle 150 Mb/s aggregate throughput while the 1335 can only handle 20 Mb/s.
I've also found this link: Creating subinterfaces for VLANs, and while I've followed similar steps, I'm still not getting connectivity.
Adtran support has been responsive and helpful; I'm just continuing to research. I'm sure they'll turn up a solution.
I'm now working on attempting to configure this setup with a /28 subnet and a /29 as a handoff address for the 3140 as a gateway address. Unfortunately, while I can get internet access to the 3140, I'm having trouble with figuring out the routing to the 1335.
WAN is connected on 3140 gig-eth 0/2. 3140 gig-eth 0/3 trunks to 1335 gig-switchport 0/2.
I've tried two different scenarios:
1. 1335 gig-switchport 0/1 connecting as x.x.193.185/28. Can't connect to anything.
2. 1335 any other switchport 10.1.1.x (DHCP). Can connect to the 1335, and ping x.x.193.184, but that's about it.
I did try (temporarily) turning off the firewall on both routers, but it didn't seem to make a difference. I'm not sure if that means the problem is not in the firewall, or just that there are multiple problems.
I'm attaching the current config from both (minus sensitive info). If you have time to look at it, I would greatly appreciate it! I've banged my head against this for several days now.
I'm still working on this. Since we are implementing VLAN routing for the first time in this environment and previously, the legacy routers were simply routing their own IP(s), I had a basic lack of understanding that I needed an additional /30 subnet from my ISP to make this work. This has been ordered and I'll take another stab at it after that.
As information for anyone finding this thread later:
At long last, we have this working. It did require the additional /30 subnet from the ISP, and our existing IP address blocks had to be reconfigured by the ISP to route through that /30 IP address--we could not just do the routing on this end. And note that this was a breaking change to our legacy setup with individual routers, so we had to do this in a maintenance window.
We ended up opting for some paid assistance from Adtran engineers (thanks Andres!), but ultimately, in a nutshell, the second optionjayh described above was pretty much what they ended up doing. We just could never make any of it work on our own to test in advance because of the routing issues with the /30 gateway, so we decided the paid option was the safer bet.