Thanks for the output of show ip interface brief. My reason for asking was to verify that the interface with the IP specified in the set command was up and operational. Your output shows that it is. What model of router is this running on? Is this live equipment or is this some simulation? Would you post the output of show ip policy?   HTH   Rick ... View more

If you are no longer able to access the switch using an IP address that used to work, then it suggests that either a change was made on the switch or that there is some issue with the switch. If you do not have access using the network IP address do you have access via the console port? If there is access via the console port then there may be some troubleshooting that you can do. Otherwise you may need to schedule a reboot of the switch and hope that it restores management connectivity.   HTH   Rick ... View more

Paul   As I read the original post I also thought about using route maps to control the address translation, since the route map allows you to match both the acl identifying traffic and match the interface.  This is the common approach when doing address translation for dual ISP - especially when outgoing traffic might be on one interface or might be on the other interface (when doing load sharing or doing failover). But in this case one set of traffic should be going out only one interface and the other set of traffic should be going out only the other interface. In that case I believe that the original nat is ok ip nat inside source list Vlan10 interface Vlan2 overload ip nat inside source list Vlan20 interface Vlan3 overload I still would like to see the outputs that I identified and would add to that a request to post the output of show ip policy   HTH   Rick ... View more

Can you post the output of show ip interface brief from the router? Can you post the output of ipconfig and the tracert from the PC?   HTH   Rick ... View more

The original post asks a fairly simple question about whether the core switch can run OSPF with a Juniper firewall while it is running EIGRP with Cisco devices and all in the same subnet. The responses are unanimous that yes this can be done. The drawing suggests a perhaps somewhat complicated environment with a Cisco firewall and a Juniper firewall. And it makes me wonder if under the surface of the simple original question is a more complicated question about how this will work and will it achieve some desired objective? Since we do not know what the desired objective is we can not address whether this will achieve it. But we can make some comments about how this will work.   As shown the core switch will maintain topology tables for both EIGRP and for OSPF and the routing table will have routes learned from Cisco devices and routes learned from Juniper. So the core switch will have routing information about both domains and can route between the domains. The Cisco devices (the firewall and other Cisco devices) will have routing information about routes originated on Cisco devices but will have no information about routes originated from Juniper. The Juniper will have routing information about its own routes but will have no information about routes originated from Cisco devices.   HTH   Rick ... View more

Thanks for the update explaining the problem. It is a very interesting (and unusual) way to create a problem.   HTH   Rick ... View more

Perhaps I have missed something or am not understanding something in what you are asking. Where is it that you suggest substituting a L3 switch for a router?   The essential part of the current problem is that you have 2 small routers/home routers. Each of them has a connected subnet. Each of them is the default gateway for the devices connected in that subnet. Each of them is doing address translation as it forwards traffic from its connected devices. And it appears that at least one of them does not support making changes in the packet forwarding logic or the address translation logic.   If you are willing to give up the 2 small routers/home routers then connecting those devices in 2 vlans on a switch would be easy and would make it easy for devices in one subnet to communicate with devices in the other subnet. It could be a layer 3 switch to do the routing. Or it could be a layer 2 switch and let the ASA do the routing.   The reason that the ASA can not do the routing in your current environment is that the source addresses have already been translated by the time the packet gets to the ASA. So the ASA has no visibility of where 10.0.1 or 10.0.2 are and is not able to route between them.   HTH   Rick   [edit] Just to be clear about your statement "My 5508-X can not be set the way I want with 2 independent Interfaces" It is not an issue about ASA with 2 independent interfaces. The ASA certainly can be configured with 2 independent interfaces. The issue is that the ASA has no visibility about where the subnets are. If a device sends a request to the NAS, when it gets to the ASA then the ASA has no idea where that destination address is or how to forward to it. ... View more

Thank you Jon. Your explanation is spot on. (so +5) Yes an LSA 3 does require a new calculation of cost but does not require running the SPF calculation. So routers in the other areas are more stable.   HTH   Rick ... View more

Most of the suggestions have focused on doing show run, copy the screen output into a file, edit the file, and paste the edited file into the new switch. I will note that it should also be possible to use the copy command on the original switch to use tftp (or ftp) to copy the config to a tftp/ftp server, edit the file, configure an interface with IP on the new switch, and use the copy command to use tftp (or ftp) to copy the edited file to the new switch.    The important part of the process is about editing the config file. For the most part you should be able to transfer the config from one switch to the other (since they are both 3750). There are some things that I would suggest that you should remove from the config before you transfer it to the new switch: - there is a line with version information. The new switch is almost certainly not the same version as the old switch. So take this out and let the new switch use its own version information. - there may be some type of boot system commands. The new switch is probably not running the same code as the original switch. So take this out and let the new switch perform its own selection of image file. Or edit the command to reflect the image information of the new switch. - I suggest that you remove any config entries related to certificates. - there may be some command with license information (and containing the device serial number). So take this out and let the new switch use its own information. - there may be a command for ntp clock-period. This is a calculated value for the original switch. Take this out and let the new switch calculate its own value.   HTH   Rick ... View more

There are multiple aspects of OSPF areas which provide advantages of implementing OSPF areas. I will mention 3 of them. 1) As Deepak mentions when a link changes state OSPF requires that the change be advertised to all OSPF routers in the area and each router must update its tables and calculate the convergence algorithm. When OSPF is implemented with a single area then a change on any router affects every router in OSPF. If you implement areas then a change on a router affects only routers in that area, and routers in other areas are more stable and do not need to process the update. 2) OSPF requires that every router in an area have the same knowledge of the routes in that area. So it is not possible to do summarization of routes within an area. Implementing OSPF with areas provides the possibility of doing summarization between areas. 3) A regular OSPF area must have knowledge of all routes (all internal routes from all areas, and all external routes). Implementing OSPF with areas provides the possibility of creating areas that do not have to know all of the routes. A stub OSPF area knows the all the internal OSPF routes but knows no external routes. It uses a default route to get to the backbone which knows all routes. A totally stubby OSPF area does not know any external routes and does not know routes from other OSPF areas. It uses a default route to get to the backbone which knows all routes. A not so stubby area is like a stub area in that it does not know of external routes from other areas. But it does allow redistribution to occur and to create external routes in the NSSA area. It uses a default route to get to the backbone which knows all routes. So these types of areas reduce the size of the OSPF tables, reduces the size of the IP routing table, and simplifies the routing logic of the router.   HTH   Rick ... View more

In your original post you correctly state that for the 2 subnets to communicate that you need a L3 device to forward traffic between them. Through the following discussion I have been assuming that the most logical solution would be to have your ASA5508 perform that function. The ASA is a L3 device that is forwarding traffic and it is already in the path used by the smaller routers. Now I have looked at the configuration of the ASA that you posted and realize that the situation is more complicated than I had realized. It appears that the smaller routers are performing address translation as they forward traffic toward their default gateway (which is the ASA). So the ASA does not know anything about subnets 10.0.1 or 10.0.2. So in the current situation the ASA can not perform the routing between those subnets.   I believe that there are several approaches that you could use, but each of the approaches has difficulty associated with it. 1) you could change the configuration of the smaller routers and have them not do address translation on traffic they are forwarding to their default gateway. This would allow the ASA to have visibility to those subnets and to forward traffic between them. But changing the configuration of the smaller routers may be more complicated than you want to undertake. 2) you could establish a connection directly between the smaller routers (which seems to be what you have in the drawing that you posted). This would allow traffic between the subnets to flow directly between the smaller routers and bypass the ASA and the address translation of the smaller routers. But this would require configuring new interfaces on the smaller routers and require changing the routing logic to forward traffic for the subnets differently than it forwards other traffic and might be more complicated than you want to undertake.   Given the architecture that you started with where the 2 smaller routers each have its own subnet and doing address translation as they forward traffic toward their default gateway, I do not see a solution that does not require significant changes in the smaller routers.   HTH   Rick ... View more

If you are concerned about the security implications of the Internet connection you may want to consider that it is as likely that someone could put a device connected to that Ethernet that is passively listening and capturing your traffic as is likely that someone would put a device on the Ethernet giving it an address in the subnet and listening to your broadcast traffic. Also think about what could they learn that was significant if they were listening to your broadcast traffic. What do you send out the Internet interface as broadcast, other than arp?   HTH   Rick ... View more