Twitter Updates

    follow me on Twitter

    Friday, April 03, 2009

    AT&T Bonded NxT1 Internet Connection: MLFR Configuration

    ---------------Configuration Start---------------------
    ! we use two VWIC-2MFT-T1 cards in Cisco 2821 router,
    ! with 3 T1 from AT&T. We bonded them
    ! and get total 4.5MB internet bandwidth.
    ! Following is the actual configuration.
    ! Hope it helps.
    ! Please let me know if any questions.
    !
    no network-clock-participate wic 0
    no network-clock-participate wic 1
    !
    !
    voice-card 0
    no dspfarm
    !
    !
    controller T1 0/0/0
    framing esf
    linecode b8zs
    channel-group 0 timeslots 1-24
    !
    controller T1 0/0/1
    framing esf
    linecode b8zs
    channel-group 0 timeslots 1-24
    !
    controller T1 0/1/0
    framing esf
    linecode b8zs
    channel-group 0 timeslots 1-24
    !
    controller T1 0/1/1
    framing esf
    linecode b8zs
    channel-group 0 timeslots 1-24
    !
    !
    interface MFR0
    no ip address
    encapsulation frame-relay IETF
    frame-relay lmi-type ansi
    !
    interface MFR0.801 point-to-point
    description WAN
    ip address x.x.x.x 255.255.255.252
    no cdp enable
    frame-relay interface-dlci 801
    !
    ! Internal LAN interface
    !
    interface GigabitEthernet0/0
    ip address x.x.x.x 255.255.255.0
    duplex auto
    speed auto
    !
    interface Serial0/0/0:0
    no ip address
    !
    interface Serial0/0/1:0
    description Circuit ID: xxxxxxxxxxx
    no ip address
    encapsulation frame-relay MFR0
    no arp frame-relay
    frame-relay multilink lid link1
    !
    interface Serial0/1/0:0
    description Circuit ID: xxxxxxxxx
    no ip address
    encapsulation frame-relay MFR0
    no arp frame-relay
    frame-relay multilink lid link2
    !
    interface Serial0/1/1:0
    description Circuit ID: xxxxxxxxx
    no ip address
    encapsulation frame-relay MFR0
    no arp frame-relay
    frame-relay multilink lid link3
    !
    interface Serial0/3/0
    no ip address
    shutdown
    !
    ip route 0.0.0.0 0.0.0.0 x.x.x.x
    !
    ---------------Configuration End-------------------



    Here are some info from Cisco:
    ==========Quote start===========

    Configuring, Verifying, and Debugging Distributed Features

    This section covers the show and debug commands that are available to verify and debug each of the distributed features.

    Configuring and Verifying dMFR

    MFR Sample Configuration

    interface MFR1
    no ip address

    interface MFR1.1 point-to-point
    ip address 181.0.0.2 255.255.0.0
    frame-relay interface-dlci 16

    Note: The MFR interface is like another FR interface and hence supports most of FR configuration.

    interface Serial5/0/0/1:0
    no ip address
    encapsulation frame-relay MFR1
    tx-queue-limit 26

    interface Serial5/0/0/2:0
    no ip address
    encapsulation frame-relay MFR1
    tx-queue-limit 26

    interface Serial5/0/0/3:0
    no ip address
    encapsulation frame-relay MFR1

    Verify MFR Bundle Status on the RP

    show frame-relay multilink

    Bundle: MFR1, State = up, class = A, fragmentation disabled
    BID = MFR1
    Bundle links:
    Serial5/0/0/3:0, HW state = up, link state = Add_sent, LID = Serial5/0/0/3:0
    Serial5/0/0/2:0, HW state = up, link state = Up, LID = Serial5/0/0/2:0
    Serial5/0/0/1:0, HW state = up, link state = Up, LID = Serial5/0/0/1:0

    This indicates that two interfaces are added correctly, and one interface has not yet negotiated the MLFR LIP messages.

    To get more information on the MFR bundle and Member links, issue this command:

    show frame-relay multilink mfr1 detailed

    Bundle: MFR1, State = up, class = A, fragmentation disabled
    BID = MFR1
    No. of bundle links = 3, Peer's bundle-id = MFR1
    Rx buffer size = 36144, Lost frag timeout = 1000
    Bundle links:
    Serial5/0/0/3:0, HW state = up, link state = Add_sent, LID = Serial5/0/0/3:0
    Cause code = none, Ack timer = 4, Hello timer = 10,
    Max retry count = 2, Current count = 0,
    Peer LID = , RTT = 0 ms
    Statistics:
    Add_link sent = 35, Add_link rcv'd = 0,
    Add_link ack sent = 0, Add_link ack rcv'd = 0,
    Add_link rej sent = 0, Add_link rej rcv'd = 0,
    Remove_link sent = 0, Remove_link rcv'd = 0,
    Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,
    Hello sent = 0, Hello rcv'd = 0,
    Hello_ack sent = 0, Hello_ack rcv'd = 0,
    outgoing pak dropped = 0, incoming pak dropped = 0
    Serial5/0/0/2:0, HW state = up, link state = Up, LID = Serial5/0/0/2:0
    Cause code = none, Ack timer = 4, Hello timer = 10,
    Max retry count = 2, Current count = 0,
    Peer LID = Serial6/1/0/2:0, RTT = 32 ms
    Statistics:
    Add_link sent = 0, Add_link rcv'd = 0,
    Add_link ack sent = 0, Add_link ack rcv'd = 0,
    Add_link rej sent = 0, Add_link rej rcv'd = 0,
    Remove_link sent = 0, Remove_link rcv'd = 0,
    Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,
    Hello sent = 7851, Hello rcv'd = 7856,
    Hello_ack sent = 7856, Hello_ack rcv'd = 7851,
    outgoing pak dropped = 0, incoming pak dropped = 0
    Serial5/0/0/1:0, HW state = up, link state = Up, LID = Serial5/0/0/1:0
    Cause code = none, Ack timer = 4, Hello timer = 10,
    Max retry count = 2, Current count = 0,
    Peer LID = Serial6/1/0/1:0, RTT = 32 ms
    Statistics:
    Add_link sent = 0, Add_link rcv'd = 0,
    Add_link ack sent = 0, Add_link ack rcv'd = 0,
    Add_link rej sent = 0, Add_link rej rcv'd = 0,
    Remove_link sent = 0, Remove_link rcv'd = 0,
    Remove_link_ack sent = 0, Remove_link_ack rcv'd = 0,
    Hello sent = 7851, Hello rcv'd = 7856,
    Hello_ack sent = 7856, Hello_ack rcv'd = 7851,
    outgoing pak dropped = 0, incoming pak dropped = 0

    MFR Debug Commands

    These debugs are useful to troubleshoot issues where a link does not get added to the bundle.

    debug frame-relay multilink control

    Note: When a specific MFR interface or Serial interface is not specified, this enables debug for all MFR links. This can be overwhelming, if the router has a large number of MFR links.

    To debug MFR packets that are received at the RP, as well as to debug the MFR control activities, this debug is useful:

    debug frame-relay multilink

    Note: Under heavy traffic, this can overwhelm the CPU.

    Verify dMLFR Bundle Status on the LC

    show frame-relay multilink

    Note: Currently, this is not available on the LC, but it will soon be added. Until then, use show ppp multilink.

    Bundle MFR1, 2 members
    bundle 0x62DBDD20, frag_mode 0
    tag vectors 0x604E8004 0x604C3628
    Bundle hwidb vector 0x6019271C
    idb MFR1, vc 0, RSP vc 0
    QoS disabled, fastsend (mlp_fastsend), visible_bandwidth 3072
    board_encap 0x60577554, hw_if_index 0, pak_to_host 0x0
    max_particles 400, mrru 1524, seq_window_size 0x200
    working_pak 0x0, working_pak_cache 0x0
    una_frag_list 0x0, una_frag_end 0x0, null_link 0
    rcved_end_bit 1, is_lost_frag 0, resync_count 0
    timeout 0, timer_start 0, timer_running 0, timer_count 0
    next_xmit_link Serial0/0:1, member 0x3, congestion 0x3
    dmlp_orig_pak_to_host 0x603E7030
    dmlp_orig_fastsend 0x6035DBC0
    bundle_idb->lc_ip_turbo_fs 0x604A7750
    0 lost fragments, 0 reordered, 0 unassigned
    0 discarded, 0 lost received
    0x0 received sequence, 0x58E sent sequence
    DLCI: 16
    769719 lost fragments, 22338227 reordered,
    0 unassigned
    27664 discarded, 27664 lost received
    0xF58 received sequence, 0x8DE sent sequence
    timer count 767176
    Member Link: 2 active
    Serial0/0:0, id 0x1, fastsend 0x60191E34, lc_turbo 0x601913AC, PTH 0x603E7030, OOF 0
    Serial0/0:1, id 0x2, fastsend 0x60191E34, lc_turbo 0x601913AC, PTH 0x603E7030, OOF 0

    =============Quote end==============
    [ link (look for MLFR]

    Thursday, April 02, 2009

    Enable "telnet://" in your Internet Explorer.

    Just in case you need to enable "telnet://" in your Internet Explorer:
    --------------
    1.  Add the Registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_DISABLE_TELNET_PROTOCOL
    2. Create a REG_DWORD (default) entry of name iexplore.exe
    3. Set that value to 0 (default).
    4. Restart IE

    -------------------------
    [ link ]

    Video Conferencing Test Sites

    ===========Quote Start==============

    IP TEST SITES:

    Dresden Germany 141.30.67.240

    Polycom Japan 61.197.225.89

    Polycom EMEA 140.242.46.50 - not always on

    Polycom Austin - lobby.austin.polycom.com - not always on

    Polycom also have a number of Ipower test systems 
    140.242.250 200
    140.242.250 201
    140.242.250 202

    Here's the test site for TANDBERG VIDEOCONFERENCING...
    TANDBERG 6000(HK)-203.194.77.168
    TANDBERG 7000 (HK)- 203.194.77.169
    TANDBERG 8000 (HK)- 203.194.77.167

    IP Address: 61.222.137.210 (Taiwan, Tandberg system). The machine may not be responding sometimes due to other use. Another one is always available. Pls dial 61.222.137.216 (DGT U&Me VideoPhone)

    Blue Star Conference Room   209.163.159.58

    LifeSize Conference Set-up 209.163.224.77
    Denver Cam (LifeSize)   64.15.104.134
    Denver Cam (Polycom VSX7000E)   64.15.104.142
    US CAPITOL 64.47.22.10
    Santiago, Chile 201.238.236.66
    Gumballs LifeSize  209.163.159.62
    Gumballs Tanberg Edge 95    209.163.159.46
    Gumballs Polycom HDX 9004   209.163.159.49
    Aquarium (Room)  209.163.159.60
    Aquarium (Express)  209.163.224.69
    TrainSize  209.163.224.76
    KittySize  209.163.224.75
    *VTC Test Callback  71.14.2.158 (Great for testing initial connections/configs.)
    HAMSTERsize: 207.114.244.82 and …83
    TOYsize: 207.114.244.85

    ===========Quote End==============

    Tuesday, March 31, 2009

    Cisco ASA: daily troubleshooting command

    Here are some commands that I use in Cisco ASA for daily troubleshooting:
    ------------------------
    1) check status:
    show version
    show conn
    show conn detail
    show xlate
    clear xlate
    show int
    show int ip brief
    show ip
    show localhost all
    show mode
    show nameif
    show route
    show route INTERFACE_NAME


    2) check configuration:
    ! check RUNNING
    show run

    ! check NAT 
    show run nat
    show run static
    show run global

    ! check OBJECTS
    show run object-group
    show run object-group | include OBJECT-NAME
    show run object-group service
    show run object-group service | include SERVICE

    ! check RULES
    show run access-list
    show run access-list | include ACCESS-LIST-NAME
    show run access-group 

    ! check INTERFACES/IP
    show run ip

    ! check APPLICATION-INSPECTION
    show run policy-map
    show run service-policy

    ! check VPN
    debug crypto ipsec
    debug crypto isakmp
    show crypto ipsec sa
    show crypto isakmp sa detail


    3) Packet Capture:
    Inside: 192.168.1.254/24
    Outside: 5.5.5.254/24
    !
    config t
    no access-list capin
    access-list capin permit ip host 192.168.1.100 host 5.5.5.100
    capture capin access-list capin interface Inside
    !
    no access-list capout
    access-list capout permit ip host 5.5.5.100 host 192.168.1.100 
    capture capout access-list capout interface Outside
    !
    clear cap capin
    clear cap capout
    !
    show cap capin
    show cap capout
    !
    -------------------------------------------
    (to be continued...)

    Monday, March 30, 2009

    MFP - Modular Policy Framework

    Modular Policy Framework(MPF) provides a consistent and flexible way to configure security appliance features. For example, you can use MPF to create a timeout configuration that is specific to a particular TCP application, as opposed to one that applies to all TCP applications.


    Configuring Modular Policy Framework consists of three tasks:

    1. class-map: Identify the traffic to which you want to apply actions. See "Identifying Traffic Using a Class Map" section.

    2. policy-map: Apply actions to the traffic. See "Defining Actions Using a Policy Map" section.

    3. service-policy: Activate the actions on an interface. See "Applying a Policy to an Interface Using a Service Policy" section.


    Examples:

    hostname(config)# class-map inspection_default
    hostname(config-cmap)# match default-inspection-traffic
    hostname(config)# class-map http_traffic
    hostname(config-cmap)# match port tcp eq 80

    hostname(config)# policy-map outside_policy
    hostname(config-pmap)# class inspection_default
    hostname(config-pmap-c)# inspect http http_map
    hostname(config-pmap-c)# inspect sip
    hostname(config-pmap)# class http_traffic
    hostname(config-pmap-c)# set connection timeout tcp 0:10:0

    hostname(config)# service-policy outside_policy interface outside

    [ Link ]

    IPSec & NAT-T

    NAT traversal is an algorithm designed to solve a common problem in TCP/IP networking: that of establishing connections between hosts in private TCP/IP networks that use NAT devices.

    NAT-T is commonly used by IPsec VPN clients in order to have ESP packets go through NAT. NAT-T (NAT-Traversal) is a process developed for enabling data protected by IPSec to pass through a NAT.

    Since IPSec either in transport or tunnel mode provides integrity for the entire IP datagram, any changes to the IP addressing (the function of a NAT) will invalidate the data.

    To overcome this issue NAT-T appends a new IP and a UDP (User Datagram Protocol) header to the incoming datagram thus ensuring that no changes are made to the incoming datagram stream.

    To enable the NAT-T in Cisco ASA:
    -------------
    asa(config)#crypto isakmp nat-t
    asa(config)#crypto isakmp ipsec-over-tcp
    -------------

    Here is a good artical at cisco.com:
    http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftipsnat.html


    And Deb Shinder has a very good explanation here:
    ==============quote start===============
    Network Address Translation (NAT) is a technology that has, in a small way, revolutionized Internet communications. NAT allows multiple computers on a LAN to share a single public IP address for accessing the Internet. Without it, the IPv4 protocol’s limited number of available addresses would be pushed to its limits. NAT also provides some measure of “cloaking” of internal computers, since they are “hidden” from external (Internet) computers that can only “see” the NAT device through which they connect.

    NAT, however, has traditionally suffered from a big shortcoming. It’s incompatible with Internet Protocol Security (IPSec), which is an increasingly popular way to protect the confidentiality and integrity of data while it’s in transit over an IP network. The solution is NAT Traversal, or NAT-T. However, there are security problems related to NAT-T – or are there? Microsoft is recommending that IPSec/NAT-T not be used to connect a Windows XP client to Windows VPN servers that are behind NAT devices, and XP Service Pack 2 changes the default behavior to prevent IPSec/NAT-T security associations to servers behind a NAT. However, some security experts are saying this is overly cautious and the threat is more theoretical than real.

    The problem with NAT and IPSec

    Why doesn’t NAT work with IPSec? Remember that the point of IPSec is not just to protect the confidentiality of the data, but also to assure the authenticity of the sender and the integrity of the data (that it hasn’t been changed in transit). The problem with NAT is obvious: NAT must change information in the packet headers in order to do its job.

    The first problem is that NAT changes the IP address of the internal computer to that of the NAT device. The Internet Key Exchange (IKE) protocol used by IPSec embeds the sending computer’s IP address in its payload, and this embedded address doesn’t match the source address of the IKE packet (which is that of the NAT device). When these addresses don’t match, the receiving computer will drop the packet.

    Another problem is that TCP checksums (and optionally, UDP checksums) are used to verify the packets. The checksum is in the TCP header and it contains the IP addresses of the sending and receiving computers and the port numbers used for the communications. With normal NAT communications, this isn’t a problem because the NAT device updates the headers to show its own IP address and port in place of the sending computer’s. However, IPSec encrypts the headers with the Encapsulating Security Payload (ESP) protocol. Since the header is encrypted, NAT can’t change it. This means the checksum is invalid, so the receiving computer rejects the packet.

    In addition, NAT isn’t able to use the port numbers in TCP and UDP headers to multiplex packets to multiple internal computers when those headers have been encrypted by ESP

    NAT-T: How it works

    The IPSec working group of the IEEE has created standards for NAT-T that are defined in RFCs 3947 and 3948. NAT-T is designed to solve the problems inherent in using IPSec with NAT.

    NAT-T adds a UDP header that encapsulates the ESP header (it sits between the ESP header and the outer IP header). This gives the NAT device a UDP header containing UDP ports that can be used for multiplexing IPSec data streams. NAT-T also puts the sending computer’s original IP address into a NAT-OA (Original Address) payload. This gives the receiving computer access to that information so that the source and destination IP addresses and ports can be checked and the checksum validated. This also solves the problem of the embedded source IP address not matching the source address on the packet.

    Note:
    This is a very simplified account of how NAT-T makes it possible for IPSec and NAT to work together. For more detailed information, see RFC 3947 at http://www.ietf.org/rfc/rfc3947.txt and RFC 3948 at http://www.ietf.org/rfc/rfc3948.txt.

    IPSec/NAT-T Security Issues

    IPSec is a security protocol. When you circumvent its normal behavior, for example by making the header information that it normally encrypts available, it makes sense that the level of security that it provides may be compromised.

    Microsoft recently revealed that the way IPSec and NAT-T work can cause a security threat wherein IPSec traffic intended for one computer may be routed to the wrong computer, if certain criteria exist. For more details, see KB article 885348.

    To prevent this problem, Microsoft recommends in the above referenced KB article that you not use IPSec/NAT-T when you have Windows Server 2003 VPN servers behind a NAT device. And to go further to prevent it, Windows XP SP2’s default behavior will not allow an XP computer to establish an IPSec/NAT-T security association with a server that’s behind a NAT.

    Is this overkill? The KB article itself states that the situation described is an uncommon one, and several security experts have reported being unable to reproduce the problem. They also point out that by killing XP’s ability to connect to servers behind a NAT, you force XP clients to use PPTP instead of L2TP for VPN connections to such servers, thus sacrificing the security advantages of L2TP.
    [ Link ]
    ==============quote end===============


    Video Conferencing through Firewall

    I managed to let the following three equipments talk to each other:
    -Polycom
    -Tandberg
    -Lifesize

    by opening the following ports in the firewall:
    ----------------------------------------
    TCP: 1719, 1720, 3230-3270, 5555-5587
    UDP: 1719, 1720, 3230-3285, 2326-2387
    ----------------------------------------


    And here is a link to a good document in Tandberg.com:
    [Tandberg & Security (pdf file)]

    ========quote start============
    The following TCP and UDP ports are relevant for TANDBERG systems.
    Port Number Service Protocol
    21 FTP/control *TCP
    23 Telnet *TCP
    80 HTTPd *TCP
    123 NTP *UDP (Codec Only)
    161 SNMP/queries *UDP
    162 SNMP/traps UDP
    443 HTTPs TCP
    963 Netlog TCP
    970 Streaming/RTP UDP
    971 Streaming/RTP UDP
    972 Streaming/RTP UDP
    973 Streaming/RTP UDP
    1026 FTP/data TCP
    1027 VNC TCP
    1719 H323/RAS UDP
    1720 H323/Q931 *TCP
    2326-2373 (2837)** H323/RTP UDP
    5555-55xx (5587)** H323/H.245/Q.931 TCP
    The first outgoing call uses 5555 for outgoing Q.931 and 5556 for H.245, next uses 5557 for
    Q.931 and 5558 for H.245, etc. Each incoming H.323 call uses the next available port for
    H.245. Disconnecting a site in a call will not free up available 55XX ports until the whole
    conference is down.
    ========quote end============

    Bill Withers - Ain't No Sunshine : enjoy it...