Re: [c-nsp] ip tcp adjust-mss
On ASR1k the MSS adjustment is done on the QFP (the ESP or in hardware). Again, this behavior varies from platform to platform. Note: IPv4 only, for now. IPv6 may be in 15.4(1)S. See http://www.gossamer-threads.com/lists/nsp/ipv6/45433 /JF ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] RE IPv6 on ASR Bug
Scott Pettit spet...@end2end.co.nz We are unable to stand up IPv6 in the following scenario: Might help to have these: show ipv6 interface show ipv6 neighbors interface Just asking... is the link up and IPv4 working? 3.7.0 is fairly recent, I'll try it in my lab setup. /JF ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IPv6 Unique Local Address Routing Issue
cisco-nsp-boun...@puck.nether.net a écrit sur 09/09/2012 07:21:13 AM : Peter Rathlev pe...@rathlev.dk So you mean the client will get one GUA together with ULA, if the client just need to communicate inside the site, then will choice the ULA, if need to access Internet, then will choice the GUA? That sounds right. And you can assign only ULA to a client that would never need to communicate with anything on the Internet, but I guess very few machines fall in that category these days. We deployed ULA+GUA in our environment, a mid-size cable ISP. We also prevent ULA-GUA communications at the datacenter edge. So far it's been working very well, only found one instance of bad source address selection in a product. Btw, we have plenty of ULA-only servers and devices. No problem on that side, but of course, we'd have to disable IPv4 to be really sure of that. ;) /JF ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Carrier grade NAT44 newest Cisco boxes
But I am not sure if regulator can send port number with IP address. Without port number bulk port allocation will be useless feature. This is why RFC6302 was written (http://tools.ietf.org/html/rfc6302). The source port will be required for any law enforcement or abuse case, because a timestamp and all connections logs aren't usually enough to prove the connection comes from a specific user on popular destinations. Anyway, good luck logging everything. For a large ISP, we're talking about petabytes of data over a year. Bulk/range port allocation is a must IMHO. /JF ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Carrier grade NAT44 newest Cisco boxes
We in europe have some pressure to have the ability to map the ip/port/timestamp touple back to user. Of course nobody will be able to deliver the port together with the ip and an accurate enough timestamp for this to be meaningfull. Bulk Port Allocation (also called Port Range Allocation) is probably what you're looking for. It reduces logging requirements by several orders of magnitudes and your timestamping doesn't have to be as precise. This is a must to deploy any CGN, IMHO. Coming soon to your favorite Cisco CGN implementation, apparently... I can see this becoming a larger problem when more nats appear on conventional DSL / FTTx / Cable access products as opposed to just low bandwidth mobile networks. Mobile networks aren't that low bandwidth anymore. They have the same issues with logging. /JF ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
