Note: Aug. 23, 2001 - This tip has been turned into TID 10064018.
This tip applies in some specific circumstances, as spelled out below. Depending on your situation / router, you may not have any problems adding another public subnet or need to use the NAT mappings
noted here.
If you are using a Cisco router for your Internet connection, and want to add another public subnet to your BorderManager public interface (because you ran out of usable addresses on the one you
have), this tip is for you. Here's the situation I ran into:
Cisco router, configured with a WAN port and LAN port, and a 255.255.255.240 subnet mask on the LAN port IP address. The .240 mask gives 14 available IP addresses, one of which is assigned to the
Cisco LAN port. The others were all assigned to the BorderManager public interface, most of them used for static NAT to web servers. Dynamic NAT was enabled on the BorderManager server for certain
outbound traffic.
Problem: 13 addresses available on BorderManager, but 15 or more were needed.
Problem: ISP cannot assign a larger subnet, but ISP did have another 255.255.255.240 subnet available.
Problem: Assigned new subnet IP address to Cisco LAN interface and added another binding to the BorderManager public interface, but could not PING the BorderManager server from the Cisco (or
the Internet).
Here are some example addresses to explain the issues:
Cisco LAN Interface:
BorderManager Public Interface:
The problem encountered was the the Cisco IP address 5.3.2.1 could be PING'd from the Internet, but not the 5.3.2.2 address on the BorderManager server. In fact, the 5.3.2.2 IP address
could not be PING'd from the Cisco that was directly attached.
An Extended PING from the Cisco router was able to successfully PING the 5.3.2.2 address. An Extended PING is done by typing PING at the Cisco router prompt and filling in values as prompted. The
only non-default entries made were to specify both the destination and source addresses for the PING. If a source address of 5.3.2.1 was used, the PING was successful.
ARP worked without a problem from both the Cisco and the BorderManager server.
The BorderManager server was able to PING the Cisco 5.3.2.1 address without a problem.
The issue is related to NAT on the BorderManager primary public IP binding. Even though NAT Implicit Filtering was disabled (same as SET NAT DYNAMIC MODE TO PASS THRU=ON), NAT was preventing the
traffic coming in on the primary network IP address 4.3.2.2 from routing to the 5.3.2.2 address on the same interface.
Solution: Use Static NAT to map the new IP bindings to themselves, or to internal hosts. For instance, once 5.3.2.2 was statically NAT'd (in the static NAT
table for 4.3.2.2) to 5.3.2.2 (NAT to itself), the Cisco could PING 5.3.2.2. Similarly, of 5.3.2.2 was statically NAT'd to an internal host, the Cisco could then PING the internal host. Once the
Cisco could access the new public IP addresses on the BorderManager server, those addresses were also accessible from the Internet.