We want to ask about ISM scalability issue. The issue are :
1. Each ISM handling 14Gbps of NAT translation.
2. We want to install 6 ISM module to handle 80Gbps NAT traffic from subs.
3. We only have one big bundled interface on the ASR router to the subscriber.
the diagram :
subscriber --- (gateway router) --- (ASR NAT router) --- internet
each link is 80Gig traffic.
(The gateway router) send all 0.0.0.0/0 traffic to (ASR NAT router)
(The gateway router) have bundled-ether(8 TenGElink) interface to (ASR NAT router)
(The gateway router) doesn't have capability to sort/classify/choose which customer ip goes to which interface to internet because of 0.0.0.0/0 to (ASR NAT router)
What is the solution for this, so that (ASR NAT router) can :
1. Can utilize all the ISM prefered active module for all subs.
2. Can have only one big insidevrf assigned to bundle-ether (8 TenGE link). And this one big insidevrf applied to all 6 ISM module.
3. Can use the same insidevrf name for each of all servicecgn that assigned to each of all 6 ISM module.
4. Can use different insidevrf name for each of 6 ISM servicecgn. But the different insidevrf share the same private IP pool from bundle-ether, but different public map pool. (because gateway router only sending 0.0.0.0/0 to ASR NAT and cannot do which subs pool goes to which interface to ASR NAT using route-map/set next hop).
5. Can the ISM module be bundled in one servicecgn. And all NAT process is spreading accross 6 module, and from customer via gateway with default gateway without doing the ACL to specify source of customer pool go to specific interface to get associated with unique vrf that get assigned to specific which ISM doing the nat work. But instead one big bundled of 6 ISM to 1 ISM processing NAT.
First, you'll have to define serviceApp interfaces for inside and outside of each ISM card (2 x 6 in your case).
Second, you can not configure a single unique map pool rang for all cards, you'll have to split your range in 6 different sub-ranges and assigned them to your cards.
----> You will be able to load-balance the inside-to-outside traffic with some tricks:
As you may know, there is a RFC recommendation stating that a given inside (source) address should always be paired to the same outside address (not "mandatory" but recommended).
Since the natural load-balancing of the router is done with various parameters including the destination address, it's always sure that the traffic from different ports of an inside address will be sent to different ISM cards and consequently translated with addresses of different pools, which is a violation of the recommendation described above.
To avoid this situation (which wouldn't dramatic, but some application "may" be affected), we recommend to make the assignation of the traffic to the different cards predictable and based on the source address. To achieve this, you'll have to rely on access-list based forwarding applied in the ingress of your bundle-ethernet interface.
The big job now will consist in identifying the source addresses and split them in different blocks. Based on these blocks you will define different next hop addresses.
Please note that this ABF approach can be extended and used for redundancy. For instance, you can define different next-hop (the ip addresses of your inside serviceApp interfaces), if the first is not reachable then you will send the traffic from this source to another address of another ISM card.
For the outside-to-inside traffic, since you have to define unique address pool for each ISM, it will be easy to define static routes pointing to the proper card for a given address.
you are right: different inside-VRFs and the ABF next-hop will point to the serviceApp interfaces in these inside-VRFs.
The ABF (like every feature applied on interface) will have the same impact than an ACL.
This performance impact of using ABF will be present at the Typhoon NPU ASICs of the line card, not the RSP440 nor the ISM board.
It's usually minimal and not a matter of concern.
More, the impact will be the same, regardless of the number of entries in your ACL.
The only important limitation to consider with ABF is that it only work on IPv4 traffic and not MPLS, so if the traffic is labeled when received on the interface, packets are not matched (and in that case some other tricks may be needed).
The Cisco EPN system incorporates a network architecture designed to consolidate multiples services on a single Multiprotocol Label Switching (MPLS) transport network. This network is designed primarily based on Application Engineered...
Internet security is important with the increasing attacks that are happening every day. Many internet and browsing security solutions exist, but some are not very easy to use or maybe the question is how can I enable them?
Cisco Software Manager Server
This document describes the programmatic interfaces, RESTful APIs, which are supported by Cisco Software Manager Server (CSM Server).
CSM Server supports a set of finite RESTful APIs. The fir...