The switch is capable of having several VLAN's or virtual lans. This comes into play if you want to separate certain types of traffic. I could see us possibly doing this and then putting a lower priority on backups and other processes that would be high bandwidth but lower importance. This would ensure that important user or system traffic would have higher priority and would not get bogged down. This would use QoS or Quality of Service. You also do not need multiple interfaces to take advantage of this, although you would have more bandwidth with multiple links. Using interface aliases on the server that have different subnets and creating multiple VLANs on one port of the switch will allow you to have 2 different vlans on the same link.
Now from a security standpoint if you are communicating with someone in the same subnet your traffic will only leave the switch on the port with the corresponding MAC address. It will never reach the internet and someone would have to be on the switch, or one of the endpoints involved in the communication to listen to it. I hope this makes things more clear but I could have just made them worse. > Davor Ocelic wrote: >> On Sun, Jan 14, 2007 at 11:46:38AM -0500, Justin S. Leitgeb wrote: >> >>> I just noticed that both mire and deleuze only have one network device >>> per server online. For some reason I imagined that we would use the >>> fact that both servers have two network interfaces to build a private >>> and and public network for our servers, so things like backup and AFS >>> could go over a connection that doesn't have a public IP and wouldn't >>> be >>> carrying traffic out to the internet. Currently deleuze only has one >>> interface listening on 69.90.123.67. >>> >>> Was there a reason for setting things up the way that they are? Should >>> we add a second private network before we go live with the servers? It >>> seems like this could allow us to use more bandwidth between servers >>> (especially for backup and fileserving purposes) and potentially >>> increase security in our configuration. >>> >>> BTW, I came across this issue when I was looking at how to set up >>> database permissions so that databases would be accessible from deleuze >>> to mire, which would be another application of having two networks, one >>> that serves to the outside world and one available internally. Let me >>> know what you think. >>> >> >> I think the switch would take care of this? Nathan and Shaun >> were discussing this, and to my understanding, the conclusion was >> the traffic would be considered local via switch, and not enter >> our bandwidth price calculation. >> >> We could make a link between the two, but then the third >> server would have no corresponding link set in the same way. >> > > I was thinking that we could partition the switch into different > subnets. Then we would have one part of the switch be for "external" > traffic and another for the private lan between servers. This would > avoid using a crossover cable between two servers... all servers would > be on both the public lan and private lan, at least until we grew to > have a need for servers that would be only on the private lan (a backup > or fileserver in the future, for example). > > I believe that based on previous conversations our switch is capable of > this. > > >> >>> _______________________________________________ >>> HCoop-SysAdmin mailing list >>> [email protected] >>> http://hcoop.net/cgi-bin/mailman/listinfo/hcoop-sysadmin >>> > > > _______________________________________________ > HCoop-SysAdmin mailing list > [email protected] > http://hcoop.net/cgi-bin/mailman/listinfo/hcoop-sysadmin > _______________________________________________ HCoop-SysAdmin mailing list [email protected] http://hcoop.net/cgi-bin/mailman/listinfo/hcoop-sysadmin
