Yes, you'd use two VLANs:
- EXTERNAL : cablemodem
- INTERNAL : LAN (10.0.0./24)
The TRUNK port to the Linux router will carry both VLANs (tagging one or both.) The linux router would then have a physical interface (eth0) and one or two vlan interfaces (eth0.X and eth0.Y -- depending on the numbers you choose for your vlans) I suggest two tagged VLANs to avoid any confusion between eth0 (untagged) and eth0.#. From there, networking is the same as having multiple physical interfaces.
(NOTE: if you use wireshark/tcdump, there are many buggy nic drivers that continue to eat vlan tags in promisc mode. As a result, capturing eth0 may not include any dot1q tags making the traffic look like it's all on the same network. Also, some management adapters will remove tags, even if the system management board isn't there. Broadcom is well known for this.)
I'm making some assumptions on your setup and how exactly your ISP is giving you these IPs, so if any of this is wrong I apologize and will happily change my answer
For your internal network I would suggest you setup a DHCP pool for your workstations and statically assign IPs to your servers. I'll leave the DHCP pool setup for you, as I think you're mainly aiming to make sure both public IPs are utilized by the proper networks.
i.e.
172.16.1.0/24 for your workstations, with DHCP, assigned to VLAN10
172.16.2.0/29 for your servers, statically assigned, on VLAN20
That all being said here is what I personally would try and setup to get your gear online.
int g0/0
ip address dhcp
This will pull an IP from your modem and give it to your external port. I suspect it will be an ISP internal IP because I doubt they'd give your modem a publicly routable IP. That'd be weird.
In this scenario, you should not be manually inputting any default routes on your router as it should all be supplied from the DHCP pull.
int g0/1.10
ip address 172.16.1.1 255.255.255.0
int g0/1.20
ip address 172.16.2.1 255.255.255.248
This setups the internal gateways for your two networks. So all your workstations will be pointing to 172.16.1.1 and your servers to 172.16.2.1
After that you'll need to setup NAT rules on the router to handle passing of traffic outwards for your workstations.
int g0/0
ip nat outside
This setups your external facing interface as your outside nat interface.
int g0/1.10
ip nat inside
This setups your internal facing interface as an inside nat interface.
Router(config)# ip nat pool internet 128.66.0.2 128.66.0.2 prefix 24
Creates a NAT pool named internet being translated to one of your public IPs.
Router(config)# ip nat inside source list 7 pool name internet overload
This says to NAT all IPs in list 7 to the NAT pool you just created and that you can overload it. Which is to say more than one internal IP can use the same external IP.
Router(config)# access-list 7 172.16.1.0 0.0.0.255
Creates the list referenced in the previous command. Now onto NAT for your servers, which I suggest be statically assigned if you want them publicly available.
int g0/1.20
ip nat inside
Same as before, this setups your internal interface as an inside NAT interface.
Router(config)# ip nat inside source static 172.16.2.(2-6) 128.66.1.(2-6)
A new line for each static assignment is needed. This creates a static translation between your internal IP and your external IP that was assigned to you.
As for your switch; all you would need to do is properly tag your ports depending on what is plugged in and make sure your trunk is passing both VLANs.
At this point both subnets should hitting your router, and your router should know where to pass the traffic, be it internally (your workstations getting to your servers) or externally (internet). Access control can either be setup with ACLs on the router, a stand-alone firewall, or firewalls on your servers.
Now this all hinges on how your ISP has your modem setup. If it works the way I think it works, when your external interface pulls it's information through DHCP, your router should populate both your public IP ranges so that when your router NATs it knows where to send your traffic.
I suspect someone will give a better written answer, but hopefully this points you in the correct direction.
I also referenced the following link for help on the NAT parts as they are definitely not something I play with very often.
http://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/13772-12.html
Best Answer
Apologies for the delay in my response, I just got back from vacation...
On this point, you are correct. Table 8 illustrates how the router would perform using a realistic combination of "enterprise" features.
Specifically, Table 8 (shown above) uses a custom IMIX (average packet size: 409 bytes) traffic stream as defined in this paper:
Given that IMIX distribution, they send unidirectional traffic using pre-defined NAT + HQoS + ACL configurations on the router, until the CPU reaches 75% load.
Take special note of the unidirectional nature of the test traffic, this unidirectional traffic is relevant to the next answer.
This is not correct; Figure 1 recommends an ISR G2 model based on Table 8, which is not a 2544 NDR test. RFC 2544 NDR tests typically run at about 90% CPU or higher. Table 8 gives you a performance sample at 75% CPU.
By way of comparison, let's look at the RFC 2544 NDR test results shown in Table 1:
Table 1 shows the Cisco 3945E can handle up to 8.675 Gbps of RFC 2544 NDR traffic; however, Figure 1 merely recommends it for a 350Mbps circuit.
There are a few of implied realities in Figure 1:
To be explicit, real networks have to use NAT (to conserve IPv4 address space), QoS to prioritize VoIP traffic, and ACLs for basic security. Every time you enable a feature like this, you're sucking packet processing power from the router; that's why there is such a big difference between the Cisco 3945E numbers shown in Table 1 (8675 Mbps) vs Table 8 (668 Mbps).
Depending on your perspective:
No based on Figure 1, you should select the Cisco 2951 or Cisco 3925; this assumes that you really will need NAT, QoS, and ACLs on that 100Mbps circuit.
The Cisco 2951 is a little light for this application at an average IMIX packet size of 409 bytes + features. If you aren't going to turn on a lot of features, or your average packet size will be much higher (as I'd expect for backup traffic), then you can get by with the Cisco 2951 (or even smaller - see my next answer).
This is a judgement call, and I don't have enough information to say. If you'd like to join me in NE chat, I could walk you through some questions to isolate this further.
The biggest question I have is whether you would need 100Mbps any time other than your PC backup case. Leveraging the reality that your average packet size is high for backup traffic, one could potentially buy an even smaller router than the Cisco 2951 if you police the traffic to the systems other than the one that needs 100Mbps for backup traffic. That said, now we are talking about a more complicated configuration; perhaps you have the money to burn on a Cisco 3925 and don't want to deal with configuration complexities.
Finally think about site growth... if this site grows rapidly, or people are prone to changing their minds about requirements on a whim, just buy the Cisco 3925 and be done with it :-).