Use Policy Routing instead of a static route, create an extended access list to match interesting traffic and define next hop IP as 83.30.280.237 using a route-map for the traffic defined in ACL. apply policy to the interface that will be used to send traffic out, using " ip policy route-map XXXX" where XXXX is the name of route map.
Dosent work. I go out with 22.214.171.124(connection work but dosent change IP) but i should with 83.30.280.238. I test it using ssh to host in 126.96.36.199.
It's funny but when I applay "ip policy route map test" to input interface not output then show route-map statistics counting, but when i applay to output as below then statistics stop, and dosent count it
access-list 116 permit ip any 188.8.131.52 0.0.0.255
route-map test permit 11
match ip address 116
set ip next-hop 83.30.280.237
set ip default next-hop 83.30.280.237
interface GigabitEthernet0/0 description internet ip address 83.30.280.238 255.255.255.252 secondary ip address 184.108.40.206 255.255.255.252 ip nat outside ip virtual-reassembly in no ip split-horizon ip policy route-map test duplex auto
I should applay route-map to incoming or outgoing interface ? Incoming is my LAN, outgoing is internet. GigabitEthernet 0/0 is internet. On other exmaples i found:
"Step 3: Apply the Route-Map to the router interface that the traffic enters into
Please apply the route map to outgoing interface....befor that, can you remove default next hop line and permit 11 from route-map. check the counters on ACL to see if traffic is being matched and also run show route-map command to what policy routing matches line reads, the counters should increment.
I have to applay ip policy route-map to my internal LAN interface(incoming) with 192.168.2.X class. Second thing is to make good maping NAT table, IP's which have to outgoing with 83.30.280.238 one nat pool, and which goes with 220.127.116.11 second nat pool. Now it's work ok THANKS.
In the first place I do not believe that Policy Based Routing will solve this issue. And if you are going to try PBR then the route map is applied to the inbound interface not the outbound interface.
Putting two different IP addresses poses some challenges in getting the router to work. If you are talking about packets sourced from the router itself the case is pretty clear - Cisco routers use the primary interface address as the source address of any packets generated by the router itself. And that seems to explain why connectivity worked when the original poster changed the order of the interface addresses.
Packets source by some inside device and routed through the router are not affected by the fact that the router always uses the primary address, unless the router is doing address translation using overload for the interface address. The original poster has not told us how they are doing address translation so we can not know whether the primary address/secondary address is impacting traffic or not.
If the address translation specifies the address or an address pool rather than interface overload then I would think that both addresses should work ok for traffic that is generated from a host inside.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...