NAT Virtual Interface

October 25, 2008 at 9:20 pm | Posted in IP Services, NAT | Leave a comment

IEWB1 Ver5 Task 13.29

Configure NAT on R5 without using any ip nat inside or outside command, so that traffic source from VLAN8 on SW2 is seen as being sourced from 155.1.188.0/24.

Configuration

R5#
int e0/0 
 ip nat enable
int s0/0
 ip nat enable
int s0/1
 ip nat enable
router rip
 redistribute static metric 1

ip nat pool NET188 155.1.188.1 155.1.188.254 netmask 255.255.255.0 add-route
ip nat source list VLAN8 pool NET188
!
!
ip access-list standard VLAN8
 permit 155.1.8.0 0.0.0.255

Verification

Rack1SW2#ping 155.1.45.4 source vlan8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.45.4, timeout is 2 seconds:
Packet sent with a source address of 155.1.8.8 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 42/47/51 ms

Rack1R5#sh ip nat tran
Pro Inside global      Inside local       Outside local      Outside global
Rack1R5#sh ip nat ?
  nvi           NVI information
  statistics    Translation statistics
  translations  Translation entries
Rack1R5#sh ip nat nvi translation
Pro Source global      Source local       Destin  local      Destin  global
--- 155.1.188.1        155.1.8.8          ---                ---

 

Doc CD Navigation

  • Cisco IOS IP Addressing Services Configuration Guide, Release 12.4
  • Part 6: NAT
  • Configuring NAT for IP Address Conservation
  • How to Configure NAT for IP Address Conservation
  • Configuring the NAT Virtual Interface

TCP Load Distribution with NAT

October 25, 2008 at 1:03 pm | Posted in IP Services, NAT | Leave a comment

IEWB1 Vol5 Task 13.26

Configure R5 so that when SW2 telnets to the IP 155.1.58.55, it is redirected to R1 R2 R4 in an even distribution.

 

R5#

ip nat pool SERVERS netmask 255.255.255.0 type rotary
 address 155.1.0.1 155.1.0.2
 address 155.1.0.4 155.1.0.4
ip nat inside destination list TELNET pool SERVERS
!
!
ip access-list extended TELNET
 permit tcp any host 155.1.58.55 eq telnet

Rack1SW2#
ip route 155.1.58.55 255.255.255.255 155.1.58.5

Alternatively, we can replace a static route on SW2 with an ip alias command on R5

Rack1R5(config)#ip alias ?
  A.B.C.D  IP address to alias to a port

Rack1R5(config)#ip alias 155.1.58.55 ?
  <0-65535>  IP port number

Rack1R5(config)#ip alias 155.1.58.55 23

 

 
Verification from SW2

Rack1SW2#telnet 155.1.58.55
Trying 155.1.58.55 … Open

Rack1R1#exit

[Connection to 155.1.58.55 closed by foreign host]
Rack1SW2#telnet 155.1.58.55
Trying 155.1.58.55 … Open

Rack1R2#exit

[Connection to 155.1.58.55 closed by foreign host]
Rack1SW2#telnet 155.1.58.55
Trying 155.1.58.55 … Open

Rack1R4#exit

[Connection to 155.1.58.55 closed by foreign host]
Rack1SW2#telnet 155.1.58.55
Trying 155.1.58.55 … Open

Rack1R1#exit

NAT for overlapping networks

October 25, 2008 at 11:36 am | Posted in IP Services, NAT | Leave a comment

IEWB1 v5 Task 13.25

R1 and R2 both have a new loopback1 with IP address of 10.0.0.0/24. Configure R1 so that R2 can access R1 loopback using IP of 11.0.0.0/24, while that traffic from R2 appear to R1 as from 22.0.0.0/24 subnet.

 

Configuration

Rack1R1#sh run | in interface|nat|ip route

interface Loopback1
 ip add 10.0.0.1 255.255.255.0
 ip nat inside
interface Serial0/0
 ip nat outside
interface Serial0/1
 ip nat outside

router rip
 network 11.0.0.0

ip route 11.0.0.0 255.255.255.0 Null0
ip route 22.0.0.0 255.255.255.0 Serial0/1

ip nat pool R2_LOOP1_POOL 22.0.0.1 22.0.0.254 prefix-length 24
ip nat inside source static network 10.0.0.0 11.0.0.0 /24
ip nat outside source list R2_LOOP1_REAL pool R2_LOOP1_POOL

 

Debugging

See a debugging sample when there’s a typo mistake in the NAT POOL
ip nat outside source list R2_LOOP1_REAL pool R2_LOO1_POOL
Rack1R1#debug ip nat detailed

*Mar  1 01:12:35.771: NAT: alloc — pool R2_LOO1_POOL not found
*Mar  1 01:12:35.775: NAT: failed to allocate address for 10.0.0.2, list/map R2_LOOP1_REAL
*Mar  1 01:12:35.775: NAT*: o: icmp (10.0.0.2, 11) -> (11.0.0.1, 11) [44]    
*Mar  1 01:12:35.775: NAT*: o: icmp (10.0.0.2, 11) -> (11.0.0.1, 11) [44]
*Mar  1 01:12:35.775: NAT*: s=10.0.0.2, d=11.0.0.1->10.0.0.1 [44]
*Mar  1 01:12:35.775: NAT: alloc — pool R2_LOO1_POOL not found
*Mar  1 01:12:35.779: NAT: failed to allocate address for 10.0.0.1, list/map R2_LOOP1_REAL
*Mar  1 01:12:35.779: NAT: translation failed (L), dropping packet s=10.0.0.1 d=10.0.0.2
no ip nat outside source list R2_LOOP1_REAL pool R2_LOO1_POOL
ip nat outside source list R2_LOOP1_REAL pool R2_LOOP1_POOL

Rack1R1#
*Mar  1 01:17:36.987: NAT*: o: icmp (10.0.0.2, 13) -> (11.0.0.1, 13) [46]    
*Mar  1 01:17:36.987: NAT*: o: icmp (10.0.0.2, 13) -> (11.0.0.1, 13) [46]
*Mar  1 01:17:36.991: NAT*: s=10.0.0.2->22.0.0.1, d=11.0.0.1 [46]
*Mar  1 01:17:36.991: NAT*: s=22.0.0.1, d=11.0.0.1->10.0.0.1 [46]
*Mar  1 01:17:36.991: NAT: i: icmp (10.0.0.1, 13) -> (22.0.0.1, 13) [46]    
*Mar  1 01:17:36.991: NAT: s=10.0.0.1->11.0.0.1, d=22.0.0.1 [46]
*Mar  1 01:17:36.991: NAT: s=11.0.0.1, d=22.0.0.1->10.0.0.2 [46]
Doc CD Navigation

  • Cisco IOS IP Addressing Services Configuration Guide, Release 12.4
  • Part 6: NAT
  • Configuring NAT for IP Address Conservation
  • Configuration Examples for Configuring NAT for IP Address Conservation
  • Allowing Overlapping Networks to Communicate Using NAT

 or

  • Translating Overlapping Address: Example

Static NAT and NAT order of operation

October 24, 2008 at 10:00 pm | Posted in IP Services, NAT | Leave a comment
IEWB1 v5 Task 13.21

Topo:
R4 ------------ R5 ------------- SW2
  155.1.45.0/24    155.1.58.0/24

The objective is to have R4 be able to telnet SW2 using 155.1.45.8, and SW2 be able to telnet R4 using 155.1.58.4

Rack1R5#sh run | in interface|nat|ip route
interface Ethernet0/0
 ip nat inside
interface Serial0/1
 ip nat outside
ip nat inside source static 155.1.58.8 155.1.45.8
ip nat outside source static 155.1.45.4 155.1.58.4
ip route 155.1.58.4 255.255.255.255 Serial0/1

The first NAT statement is straigh forward. It is used so that outside world can see SW2 VL58 with the IP off 155.1.45.8.

155.1.58.8 is Inside Local
155.1.45.8 is Inside Global

We need to translate Inside traffic. As the direction is Inside to Outside, those above IP addresses are SOURCE IP. That’s why we need “ip nat inside source static”
The second NAT statement is less usual. It is used for the second task so that SW2 can telnet R4 using 155.1.58.4

155.1.45.4 is Outside Global
155.1.58.4 is OUtside Local

As the direction is from Outside to Inside, those IP are Source. That’s why we need “ip nat outside source” translation.

NAT order of operation:

As traffic arrives on an outside interface, it is NAT translated, before being routed. Therefore, we do not need static route for 155.1.45.8, because traffic from outside, destined for 155.1.45.8 have the destination IP translated to 155.1.58.8 which is already routeable.

On the other hand, traffic arriving on an inside interface is routed, before translated.
When R5 received traffic from Local LAN heading to 155.1.58.4, it does not know that it need to route toward R4, unless we have the static route for the host route 155.1.58.4/32 configured, which overrides the connected route for the LAN subnet 155.1.58.0/24.

BTW, we do not need static route for 155.1.58.4/32 on SW2, because the above route is automatically advertized into RIP by R5 and SW2 will have it installed as a RIP route. Static routes pointing to an interface (instead of a next-hop IP address) are treated as directed route by RIP.

Rack1R5#sh ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
--- ---                ---                155.1.58.4         155.1.45.4
--- 155.1.45.8         155.1.58.8         ---                ---
R5#debug ip nat detailed
*Apr  7 02:55:54.571: NAT: i: icmp (155.1.58.8, 9) -> (155.1.58.4, 9) [61]    
*Apr  7 02:55:54.571: NAT: s=155.1.58.8->155.1.45.8, d=155.1.58.4 [61]
*Apr  7 02:55:54.571: NAT: s=155.1.45.8, d=155.1.58.4->155.1.45.4 [61]
*Apr  7 02:55:54.603: NAT*: o: icmp (155.1.45.4, 9) -> (155.1.45.8, 9) [61]
*Apr  7 02:55:54.603: NAT*: s=155.1.45.4->155.1.58.4, d=155.1.45.8 [61]
*Apr  7 02:55:54.603: NAT*: s=155.1.58.4, d=155.1.45.8->155.1.58.8 [61]
*Apr  7 02:55:54.607: NAT: i: icmp (155.1.58.8, 9) -> (155.1.58.4, 9) [62]    
*Apr  7 02:55:54.607: NAT: s=155.1.58.8->155.1.45.8, d=155.1.58.4 [62]
*Apr  7 02:55:54.607: NAT: s=155.1.45.8, d=155.1.58.4->155.1.45.4 [62]
*Apr  7 02:55:54.635: NAT*: o: icmp (155.1.45.4, 9) -> (155.1.45.8, 9) [62]
*Apr  7 02:55:54.635: NAT*: s=155.1.45.4->155.1.58.4, d=155.1.45.8 [62]
*Apr  7 02:55:54.635: NAT*: s=155.1.58.4, d=155.1.45.8->155.1.58.8 [62]

More info on Nat order of operation

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml

IRDP – ICMP Router Discovery Routing Protocol

October 23, 2008 at 1:55 pm | Posted in IP Services | Leave a comment

This is a less well-known First Hop Redundancy protocol, as compared to HSRP, VRRP, and GLBP. It is based on ICMP.

SW2# 

interface Vlan58
 ip address 155.1.58.8 255.255.255.0
 ip irdp
 ip irdp maxadvertinterval 20
 ip irdp minadvertinterval 10
 ip irdp address 155.1.58.8 200

Rack1R5#
!
interface Ethernet0/0
 ip address 155.1.58.5 255.255.255.0
 ip irdp
 ip irdp maxadvertinterval 20
 ip irdp minadvertinterval 10
 ip irdp address 155.1.58.5 100

Rack1R5#sh ip irdp e0/0
Ethernet0/0 has router discovery enabled

Advertisements will occur between every 10 and 20 seconds.
Advertisements are sent with broadcasts.
Advertisements are valid for 60 seconds.
Default preference will be 0.
Proxy for 155.1.58.5 with preference 100.

Rack1SW2#sh ip irdp vlan58
Vlan58 has router discovery enabled

Advertisements will occur between every 10 and 20 seconds.
Advertisements are sent with broadcasts.
Advertisements are valid for 60 seconds.
Default preference will be 0.
Proxy for 155.1.58.8 with preference 200.

Disable SW1 routing, to simulate a host.

Rack1SW1(config)#no ip routing
Rack1SW1(config)#ip ?
 gdp                   Router discovery mechanism

Rack1SW1(config)#ip gdp ?
  eigrp  Discover routers transmitting EIGRP router updates
  irdp   Discover routers transmitting IRDP router updates
  rip    Discover routers transmitting RIP router updates

Rack1SW1(config)#ip gdp irdp

Rack1SW1#sh ip route  
Gateway         Using  Interval  Priority   Interface
155.1.58.8      IRDP       14       200     Vlan58
155.1.58.5      IRDP       14       100     Vlan58

Default gateway is 155.1.58.8

Host               Gateway           Last Use    Total Uses  Interface
ICMP redirect cache is empty

Rack1SW1#trace 155.1.10.10

Type escape sequence to abort.
Tracing the route to 155.1.10.10

  1 155.1.58.8 8 msec 0 msec 0 msec
  2 155.1.108.10 0 msec *  0 msec

Rack1SW1#trace 155.1.45.4

Type escape sequence to abort.
Tracing the route to 155.1.45.4

  1 155.1.58.8 0 msec 8 msec 0 msec
  2  *
    155.1.45.4 1015 msec *
Rack1SW1#trace 155.1.45.4

Type escape sequence to abort.
Tracing the route to 155.1.45.4

  1 155.1.58.5 8 msec 0 msec 9 msec
  2 155.1.45.4 17 msec *  8 msec

Rack1SW1#trace 155.1.0.5

Type escape sequence to abort.
Tracing the route to 155.1.0.5

  1 155.1.58.8 0 msec 8 msec 0 msec
  2 155.1.58.5 0 msec *  0 msec
Rack1SW1#trace 155.1.0.5

Type escape sequence to abort.
Tracing the route to 155.1.0.5

  1 155.1.58.5 8 msec *  0 msec

DHCP for PPP Link (revisited)

October 21, 2008 at 11:08 pm | Posted in IP Services | 1 Comment

Another caveat found today, in relation to the topic posted previously. https://enotepad.wordpress.com/2008/09/25/dhcp-for-ppp-link/

It is found when I do the WB Vol1 IP Services, Task 13.7 DHCP Proxy.

The Caveat:

When we specify DHCP server address, make sure that the IP address should be the source of the return “IP address offer” packet from the DHCP server. It is very relevant when the DHCP server has more than 1 path to the client.

If we specify one IP address, e.g. 155.1.67.6, while the return path from DHCP server exit another interface with IP address of 155.1.146.6, then the client will reject the offer, due to the “server not in approved list”.

 

R3#
 ip dhcp-server 155.1.67.6
 
*Mar  1 22:37:10.151: DHCP Offer Message   Offered Address: 155.1.23.2
*Mar  1 22:37:10.151: DHCP: Lease Seconds: 86400    Renewal secs:  43200    Rebind secs:   75600
*Mar  1 22:37:10.151: DHCP: Server ID Option: 155.1.146.6
*Mar  1 22:37:10.151: DHCP: offer received from 155.1.146.6
*Mar  1 22:37:10.151: DHCP: offer: server 155.1.146.6 not in approved list
R3#
ip dhcp-server 155.1.67.6
ip dhcp-server 155.1.146.6
*Mar  1 22:40:48.675: DHCP Offer Message   Offered Address: 155.1.23.2
*Mar  1 22:40:48.675: DHCP: Lease Seconds: 86400    Renewal secs:  43200    Rebind secs:   75600
*Mar  1 22:40:48.675: DHCP: Server ID Option: 155.1.146.6
*Mar  1 22:40:48.675: DHCP: offer received from 155.1.146.6
*Mar  1 22:40:48.675: DHCP: offer received in bad state: Requesting  punt
*Mar  1 22:40:48.863: DHCP: XID MATCH in dhcpc_for_us()
*Mar  1 22:40:48.863: DHCP: Received a BOOTREP pkt
*Mar  1 22:40:48.863: DHCP: Scan: Message type: DHCP Ack
*Mar  1 22:40:48.863: DHCP: Scan: Server ID Option: 155.1.146.6 = 9B019206
*Mar  1 22:40:48.863: DHCP: Scan: Lease Time: 86400
*Mar  1 22:40:48.863: DHCP: Scan: Renewal time: 43200
*Mar  1 22:40:48.867: DHCP: Scan: Rebind time: 75600
*Mar  1 22:40:48.867: DHCP: Scan: Subnet Address Option: 255.255.255.0
*Mar  1 22:40:48.867: DHCP: rcvd pkt source: 155.1.146.6,  destination:  155.1.23.3
*Mar  1 22:40:48.867:    UDP  sport: 43,  dport: 43,  length: 308
*Mar  1 22:40:48.867:    DHCP op: 2, htype: 1, hlen: 6, hops: 0
*Mar  1 22:40:48.867:    DHCP server identifier: 155.1.146.6
*Mar  1 22:40:48.867:         xid: 1DC0, secs: 0, flags: 0
*Mar  1 22:40:48.867:         client: 0.0.0.0, your: 155.1.23.2
*Mar  1 22:40:48.867:         srvr:   0.0.0.0, gw: 155.1.23.3
*Mar  1 22:40:48.867:         options block length: 60

Why can’t I ping btw different IP subnets on same VLAN!

October 21, 2008 at 6:19 pm | Posted in IP Services, Routing | 1 Comment

I came accross an interesting question, where we have a two routers, on the same VLAN, but are configured with IP belonging to different subnets(e.g 101.1.1.1/24 on one router and 102.1.1.1/24 on another router). No matter we configure static routes and proxy-arp, local proxy-arp, the two routers still cannot ping each other!

Here is the reason behind it.

By default, when routing is enabled, routers will not respond to arp requests from stations whose source IP addresses are not on the IP subnet that receives the request, regardless of whether proxy arp or local proxy arp is enabled or not.

When R1 try to ARP for R2 IP address, R2 will see the ARP comes from 101.1.1.1 on the interface that has IP of 102.1.1.1/24, and will ignore it.

R2#

*Mar  1 06:39:11.166: IP ARP req filtered src 101.1.1.1 0000.1111.1111, dst 101.1.1.2 0000.0000.0000 wrong cable, interface FastEthernet0/0
To disable this sanity check, you will have to use any of the following solutions:

1. Static ARP

R2#
arp 101.1.1.1 0000.1111.1111 arpa

2. Local Area Mobility (LAM)

R2#
interface FastEthernet0/0
mac-address 0000.2222.2222
ip address 102.1.1.1 255.255.255.0
ip mobile arp

See the debug message that R2 now does not complain any more about ARP from wrong subnet!
R2#
*Mar  1 06:43:15.334: IP ARP: rcvd req src 101.1.1.1 0000.1111.1111, dst 102.1.1.1 FastEthernet0/0 *Mar  1 06:43:15.334: IP ARP: sent rep src 102.1.1.1 0000.2222.2222,
dst 101.1.1.1 0000.1111.1111 FastEthernet0/0

3. Disable routing on both routers.

4. Configure secondary IP address.

The Local Proxy Arp or Proxy Arp are not required here.

- Local proxy arp is used, so that a router can work as proxy for two hosts on the same subnet, which normally can not communicate directly (e.g. Private VLAN or on protected port).

- Proxy arp (on by default) is used so that router responds on any ARP for subnets outside LAN subnet (e.g. when you have a default static route on R1 pointing to e0/0, instead of R2 LAN IP, you will need to enable R2 proxy arp (on by default).

As said above, both these options does not work in this case, because we have different IP subnets on the two routers, and by default, routers just ignore ARP request from each other.

DHCP For PPP Link

September 25, 2008 at 6:06 pm | Posted in IP Services | 1 Comment

I came accross an weird issue today when practicing Vol2 Lab 13, Task 2.3: The R4 Serial interface was  not able to get IP address via DHCP, until i changed the R5 Serial0/1 to use unnumbered off Loopbac1, instead of manual IP.

This could be because of routing for the subnet 139.1.45.0/24 is not available, till the interface is fully up, by then IPCP is no longer negotiating IP address for the Serial interface. The loopback interface fix arround this issue. It may also because of other hidden issue I am not aware of. Anyway, this issue is a good candidate for the IOS bug, or weird caveat that need to remember by heart.

[21 Oct 2008] Also see other related issue found at https://enotepad.wordpress.com/2008/10/21/dhcp-for-ppp-link-revisited/

[22 Oct 2008]

This issue has been confirmed in the IEWB Vol1 ver5. We ether need to use ip unnnumbered off a loopback, or static routing for that Serial PPP interface. This is needed because the Serial link isn’t in the UP/UP state until IP is acutally negotiated. This means that when the proxy request is received at the server, the server does not have a route back to the relay in order to send the reply back.

This can be observed by turning on “debug ip packet details” on the server, and we can see that DHCP reply packets (UDP src=67, dst=67) are unroutable.

RSRack1R5#sh run int s0/1
interface Serial0/1
ip address 139.1.45.5 255.255.255.0
encapsulation ppp
peer default ip address dhcp

ip dhcp-server 139.1.15.1

RSRack1R4#sh ip int s0/1
Serial0/1 is up, line protocol is up
Internet address will be negotiated using IPCP
Broadcast address is 255.255.255.255
Peer address is 139.1.45.5
MTU is 1500 bytes

RSRack1R4#sh ip int brief | in Serial0/1
Serial0/1                  unassigned YES IPCP   up                    up

Change to use IP unnumbered on R5

RSRack1R4#sh run int s0/1
interface Serial0/1
ip address negotiated
ip rip advertise 3
encapsulation ppp

RSRack1R5#sh run
!
interface Serial0/1
ip unnumbered Loopback1
encapsulation ppp
peer default ip address dhcp

interface Loopback1
ip address 139.1.45.5 255.255.255.0

ip dhcp-server 139.1.15.1

RSRack1R4#sh ip int s0/1
Serial0/1 is up, line protocol is up
Internet address is 139.1.45.4/32
Broadcast address is 255.255.255.255
Address determined by IPCP
Peer address is 139.1.45.5

RSRack1R4#sh ip int brief | in Serial0/1
Serial0/1                  139.1.45.4 YES IPCP up                    up

Web-caching WCCP

August 28, 2008 at 11:56 pm | Posted in IP Services | Leave a comment

Enable webcaching, and securing only WCCP server from certain IP

access-list 99 remark Web-cache server
access-list 99 permit 129.1.3.33

access-list 100 remark Host on the subnet to bypass web-caching
access-list 100 deny   tcp host 129.1.3.100 any eq www
access-list 100 permit ip any any

ip wccp web-cache group-list 99 redirect-list 100

! Alternatively if we just want to enable web-caching without specifying ACL
ip wccp web-cache

interface FastEthernet 0/0
ip wccp web-cache redirect in

! The following to exclude an interface from webcaching.

interface FastEthernet 0/1
 ip wccp redirect exclude in

! Excluding an interface from webcasing should be used
! when we specify an interface e.g. S0/0 for redirecting
! traffic going out of that interface, comming from any interfaces

interface Serial0/0
 ip wccp web-cache redirect out
WCCP Outbound ACL Check

The following configuration example shows that the access list prevents traffic from network 10.0.0.0 leaving Fast Ethernet interface 0/0. Because the outbound ACL check is enabled, WCCP does not redirect that traffic. WCCP checks packets against the ACL before they are redirected.

ip wccp web-cache

ip wccp check acl outbound

interface fastethernet0/0

ip access-group 10 out

exit

ip wccp web-cache redirect-list redirect-out

access-list 10 deny 10.0.0.0 0.255.255.255

access-list 10 permit any

If the outbound ACL check is disabled, the HTTP packets from network 10.0.0.0 would be redirected to a web cache. Users with that network address could retrieve web pages even though the network administrator wanted to prevent it.

Doc CD Navigation

  • Cisco IOS IP Application Services Configuration Guide, Release 12.4

  • Configuring WCCP

  • Configuration Examples for WCCP

TCP Customization

August 28, 2008 at 8:25 pm | Posted in IP Services | Leave a comment
Rack1R3(config)#ip tcp ?
  async-mobility      Configure async-mobility
  chunk-size          TCP chunk size (to change max of characters that 
                      TCP reads from the input queue for Telnet and rlogin)
  ecn                 Enable Explicit Congestion Notification
  intercept           Enable TCP intercepting
  mss                 TCP initial maximum segment size 
  path-mtu-discovery  Enable path-MTU discovery on new TCP connections
  queuemax            Maximum queue of outgoing TCP packets
  selective-ack       Enable TCP selective-ACK
  synwait-time        Set time to wait on new TCP connections
  timestamp           Enable TCP timestamp option
  window-size         TCP window size

Doc CD Navigation

  • Cisco IOS IP Application Services Configuration Guide, Release 12.4
  • Configuring TCP
Next Page »

Blog at WordPress.com. | The Pool Theme.
Entries and comments feeds.

Follow

Get every new post delivered to your Inbox.