Sometimes MTU issues arise, particularly with PPPoE on Cisco DSL CPE. These can be addressed by changing the TCP Maximum Segment Size (MSS) on the pertinent interface:

interface Dialer1
  ! ...
  ip tcp adjust-mss <size in bytes>
  ! ...

To see a brief list of the interfaces so you can drill down and get more information run:

router# show ip int bri

If you want to view your PAT for debugging:

pixfirewall# show xlate debug

If you want to forward a port on a public interface on a Cisco device performing NAT firewalling (PIX excluded, I'm sure it's got something special) to a port on a private host, it is necessary to perform destination NAT (inside source NAT):

ip nat inside source static <tcp/udp/etc> <private IP> <private port> <public IP> <public port> extendable

Example:

ip nat inside source static tcp 192.168.1.100 22 66.188.71.74 22 extendable

1. Define an ISAKMP numbered policy with encryption algorithm and authentication mode:

   crypto isakmp policy 1
     encryption 3des
     authentication pre-share
   

2. Define a shared key to accept from the other endpoint of the tunnel:

   crypto isakmp key <key> address <IP address of remote endpoint>
   

3. Define ISAKMP keepalive settings if applicable, for dead peer detection. Parameters are in seconds:

   crypto isakmp keepalive <keepalive interval> <# retries on keepalive failure>
   

4. Define a named IPSec transform set, which is a Cisco abstraction for a certain combination of protocols to be applied to a particular conduit:

   crypto ipsec transform-set <name> esp-3des esp-sha-hmac
   

5. Define named crypto maps, another Cisco abstraction that aggregates various elements of an IPSec Security Association (SA). This requires a stanza that defines the remote endpoint, the transform-set used, and the mandatory access list which determines the traffic to which IPSec transformation should be applied.

   crypto map <name> <number, e.g. 1> ipsec-isakmp 
     set peer <IP of remote peer>
     set transform-set <name of transform-set above> 
     match address <access list number>
   

6. Create the access list entry referenced in step #5, and permit the GRE protocol to the remote endpoint using a host entry:

   access-list <number> permit gre host <local IP> host <endpoint IP>
   

7. Create the actual GRE tunnel interface through which to transport traffic to the endpoint. The peer and the physical interface through to which the tunnel endpoint should be bound need to be specified:

   interface Tunnel0
     ! If applicable, i.e. numbered interface.
     ip address <link subnet IP> <link subnet mask> 
     ! The rest:
     tunnel source <public interface>
     tunnel destination <remote endpoint IP>
   

8. Apply the crypto map to the physical interface on which tunnel-associated traffic will be going out:

   interface <public interface>
     ...
     crypto map <map name>
     ...
   

9. Set a static route by interface to the remote network, if applicable:

   ip route <remote net> <remote netmask> Tunnel0
   

If your BGP neighbour is a Cisco unit (and possibly others), it is possible to reprocess all learned routes and new announcements without clearing and retransmitting the full contents of the BGP table. This is known as a "soft reconfiguration," and is supported as of IOS 12.0. This avoids fast route cache invalidation, network service disruption, and other results associated with wiping the BGP table that would normally be undesirable, although it is more memory-intensive:

Router# clear ip bgp <neighbor IP, AS number, or *> in

To trigger a release of updates toward a neighbor in a similar fashion:

Router# clear ip bgp <neighbor IP, AS number, or *> out

Setting terminal length (ignore -more- prompts) on various devices:

term len 0 (cisco)
set cli screen-length 0 (juniper junos)