[c-nsp] SUP720-3B and NAT performance

Peter Salanki peter.salanki at bahnhof.net
Thu Mar 1 14:23:04 EST 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

1) Upgrade IOS
2) Check logs so it doesn't say something with conflicting flowmasks.  
You can't do NDE while doing hardware assisted NAT.

If NAT is done in hardware, no CPU increase would be noticeable.

Sincerely

Peter Salanki
CTO
Bahnhof AB (AS8473)
www.bahnhof.se
Office: +46855577132
Cell: +46709174932

1 mar 2007 kl. 20.02 skrev Elmar K. Bins:

> Hey specialists,
>
> I run a couple of SUP720-3B here that - for providing redundancy
> over PA space to our VPN site-to-site tunnels - need to NAT one
> address each to the outside.
>
> We're using the tunnels in a preliminary setup and have just seen
> that this seems to be the limit to which we can push the transport:
>
> Vlan5 is up, line protocol is up
> ...
>   30 second input rate 40267000 bits/sec, 8710 packets/sec
>
> Router CPU is at 100% while pushing that bit. IP NAT statistics
> show one miss and several million hits.
>
> IOS version is 12.2(18)SXE6a, so the NAT should be hardware assisted
> and be pushable to 20 Mpps (Cisco theoretical max, but I'd be happy
> with 10).
>
> I'm looking for either an oversight on my part, a magic thingy, or an
> alternative solution here, since we need to push at least 300 Mbps  
> over
> the tunnels, and we'd like to have the headroom the VPN devices  
> give us
> (up to 1 Gbps independent of packet size).
>
> I'm not sure whether I have to configure anything special to get
> the benefit of hardware assisted NAT. Setup here is, well, maybe
> not really straightforward, but not rocket science:
>
> =================================================================
> interface Vlan5
>  ip address 81.91.x.x 255.255.x.x
>  ...
>  ip nat outside
>
>
> interface Vlan11
>  ip address 10.121.x.x 255.255.x.x
>  ip nat inside
>
> ip nat inside source list NAT-LIST interface Vlan5 overload
> ip nat inside source static esp 10.121.x.y interface Vlan5
>
> Extended IP access list NAT-LIST
>     10 permit udp host 10.121.x.y eq isakmp host 81.91.x.z eq isakmp
>     20 deny ip any any
> =================================================================
>
>
> There's nothing in between the routers but a straight GBit ethernet  
> line,
> the setup looks (kind of graphical) like this:
>
>  +-----+                +----+
>  | VPN |-(10.121.x.y)---| RT |-(81.91.x.x)----+
>  +-----+                +----+                |
>                                               | (10 km of best GigE)
>  +-----+                +----+                |
>  | VPN |-(a.b.c.d)------| RT |-(81.91.x.z)----+
>  +-----+                +----+
>
> (Config above is from the upper RT)
>
>
>
>
> So, my questions are:
>
>   - is this normal, can I really not push more?
>   - if I can push more
>     . did I omit a magic command ("hardware-assist nat please")?
>     . can the reason be the NAT-LIST?
>     . could I get it going by not checking for protocol and port?
>
>   - if I can't
>     . can I get sufficient performance out of GRE tunnels?
>       (we can still change the design a bit here)
>
> I'm pretty turned off here, and I'm ready to shout at Cisco, provided
> I didn't omit a config command I should have used ;)
>
>
> Alright, anyone have an idea to this? Thanks in advance.
>
> Elmar "and the design looked so neat and clean"
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFF5ygaiQKhdiFGiogRAhftAJ9Mpyj0F28kqqPGZDOO4m0xJXmGxACfV7QH
Z3zhrHyfdDaZMusSxj6bZow=
=A0cp
-----END PGP SIGNATURE-----


More information about the cisco-nsp mailing list