sjw's questions

We have an ISP (ISP1), with a router maintained by the ISP. We are bringing up a 2nd ISP (ISP2), with routers we will deploy and maintain. We'd like to gradually migrate services from ISP1 to ISP2, eventually phasing out the original ISP. We'd like the migration setup to support default routing of traffic we haven't selected to go to ISP1, to default out ISP2 during the phase out.

We currently support IPsec tunnels, AnyConnect vpn and various applications on the existing ISP1, with a public /24 provided by the ISP. Please see the attached topology image for the current setup, and concept of the state we expect during the migration. The ISP2 is providing a new /24 that all tunnels and applications will need to move to.

Unfortunately, the ASA 5510 does not support PBR (policy based routing), so I'm looking for a solution to support this setup, while maintaining connectivity to all applications on ISP1 during the migration. Specifically, I am concerned about how to manage routing outbound from our ASAs to the appropriate interface and next hop, given the topology. I believe the IPsec tunnels would be fairly straightforward, requiring just a static route to each tunnel peer out the ISP1 upstream router. As the tunnels are migrated, I'd remove the static route to allow it out ISP2.

I believe I can use Egress Interface Routing (cisco doc) to ensure application traffic is addressed and routed appropriately, but am not confident I understand the implications/requirements of this and would like feedback on whether this would work, or possible alternative solutions to handle the routing setup on the ASAs.

Thanks for any & all feedback!

We have an ASA 5505 with a VLAN setup for each of outside, inside and two dmz interfaces. The outside interface is set to security level 0, inside set to 100, and both dmz interfaces set to 50.

Unfortunately, the device is not passing traffic from one of the dmz interfaces (other is currently disabled) to the outside interface by default, as I'm expecting. I'm expecting that going from higher security to lower security, traffic should not get caught by an implicit ACL. However, the packet-tracer tool shows this to be the case - that it is getting blocked at step2 by an implicit ACL. I added an ACE to allow traffic to outside IPs, and the traffic does flow now. However, this shouldn't need to be done. It will create a management burden going forward, defining all allowed ranges of IPs, ports, protocols, etc.

The license on the ASA has Security Plus. Show version lists:

Cisco Adaptive Security Appliance Software Version 8.4(4) Device Manager Version 6.4(9)

Licensed features for this platform:

Maximum Physical Interfaces : 8 perpetual

VLANs : 20 DMZ Unrestricted

I would like to add a shared virtual disk to a second VM which is already attached to a first VM. They will have shared access to the disk, via SCSI controllers set to virtual bus sharing.

This works fine via the vCenter GUI, but I'd like to do it via PoweCLI.

I can't find a way to attach a new SCSI controller to the second VM, without passing in the existing hard disk as an argument to the new-scsicontroller cmdlet. Unfortunately, this results in a new SCSI controller on the first VM, not the second VM.

Any ideas how to do this with the vSphere API, or other techniques?

We're having an issue with DNS clients not being able to resolve certain FQDNs. Within the same domain in which the problem occurs, doing an nslookup against a host name works. However, an nslookup against the hostname.domain.parentdomain1.parentdomain2.net doesn't work. Weird, from outside that domain, the same FQDN query works. Clients in both domains are using the same DNS servers, which are in the "parentdomain1" example.

The nslookup comes back with:

Non-authoritative answer: Name: hostname.domain.parentdomain1.parentdomain2.net.parentdomain2.net Address: 209.62.20.188

So, the client is appending the "parentdomain2.net" twice.

Would appreciate any assistance.

Changing the default or preference to remove the banner sheets doesn't get enforced on the client's settings unless you have the client delete the printer object, and reconnect to the server's print share again.

Any ideas how to enforce this setting on Windows clients? FWIW, these are XP clients connecting to a Win 2003 print server.