2011-03-22 06:00 AM
The source IP will be one of the 3 "aliases" you have if they are all within the same subnet.
This is one of the "beginner" mistakes of using multiple IP addresses within a single subnet. For the kernel, all IP's within a subnet have an identical value as far as IP traffic is concerned, so it will just pick a random source IP from among the aliases. The problems start when things like firewalls are introduced and asymetric traffic flows start to show up.
Depending on how much influence you have on your network setups, try to avoid using aliases like this and rather segregate your net into separate subnets (and vlans). This, of course, can mean a bit more complex routing setup if you are offering services to multiple networks that have even more networks behind them. Perhaps a separate vlan for snapmirror traffic is a good place to start.
2011-03-22 06:09 AM
So the replication traffic will not have a src IP of the VIF?!
The solution you gave will be very confusing to implement as we will also be using mutistore - One VIF (4 x 1Gb links) will have multiple vlans (one per customer / vfiler) and each vlan will have an IP and 3 aliases (for IP load balancing).
Are there any other ways we can make sure replication comes from only 1 designated IP?
2011-03-22 06:27 AM
If you are doing "vfiler to vfiler" snapmirror, then the rules are the same. Each multistore/vfiler context has a separate routing table. These work the same as on any other server. There is no guarantee for source addresses if you have 3 IP on the (connection) source side in the same subnet. If you are doing vfiler to vfiler mirroring, then IP filtering shouldn't be a big deal anyway. All of the data belongs to the same customer, most likely.
Here you could introduce also a second subnet (and vlan) into each vfiler for snapmirror traffic with a host route (and the correct snapmirror source hostname) to make sure that the traffic is using the right net. You can only use one ipspace (that means only one routing table and one default route) per vfiler, so you'll need the "host route" hack.
You could also do all of your snapmirror work via vfiler0 and just avoid the issue, if you don't have separate WAN connections per customer. It would be infinitely simpler.
A bit of the confusion here is the juxtaposition of snapmirror source filer and snapmirror source connection IP, perhaps. Since the updates are started from the snapmirror destination, this is the source IP for the connection even if it is on the snapmirror destination. Yes, it sounds a bit confusing, but it really isn't.
You can force snapmirror to check the IP, but that won't change the source IP address of the connection, because that is a matter of routing, and your aliases all have equal value as a source IP for the connection.
There is no "source routing" on ONTap, and frankly, I am happy for that. It makes people have to understand routing and not just "make it work".
2011-03-22 08:23 AM
The vfilers will host data that should be securely partitioned and each vfiler will require an ipspace - Also, each vfiler will replicate data through separate network infrastructure and WAN links (once it has routed off the storage infrastructure).
With this is mind I can only have one subnet / VLAN (ipspace) so can't separate my replication traffic to a VLAN with a single IP??? Can I?
2011-03-22 09:56 AM
Was a solution found out for this problem.can you please share it.
We also have a similar kind of setup ..so what I did for the snapmirror is - use the IP address of the backup VLAN ( we have a seperate vlan for backup dedicated) and it went on fine.
Maybe this would help.
2011-03-22 01:25 PM
As in my previous post, as I need separation using ipspaces I can only have on vlan per vfiler and this would prevent me from being able to use a separate vlan for snapmirror replication. This leaves me with having to allow all IPs (vif + aliases) through an ACL for snapmirror - Can anyone confirm if I am right or wrong?
2011-03-22 02:35 PM
I guess you probably haven't said enough about your setup. If you are just trying to run a segregated setup for VMWare and have the multiple aliase for multi-connection iSCSI, then that could be a "private" vlan, that is, only reachable from the local servers. This net wouldn't need to have a default route, necessarily, depending on what your DR setup is (do the servers have to be able to reach the snapmirror destination directly?) Then you could have a second vlan for snapmirror traffic where the default route is. There is no problem having multiple vlans per vfiler, but only one ipspace and one default route.
Either way, both the primary and secondary vfilers have the same data and should be in the same security zone, so I am having a bit of a problem understanding the ACL requirements anyway.
Using all of these address might not get you what you are looking for anyway. Using 1 GE interfaces for server-storage connections is rapidly reaching the end of its usefulness. The complexity of all of the extra ip addresses to hack multi-connection iscsi when there is no deterministic behavior forcing an even balance of traffic among your 1 GE links might just be more work that it is worth. Depending on your actual customer needs, a 10 GE net might be worth thinking about.
In any case, I guess the realities of the routing situation should be clear. The other suggestion here is a bit like I also suggested. Your options should be pretty clear by now.