Pete’s Packet

I don’t think I can. I know I can!

Archive for the ‘Uncategorized’ Category

Nexus 1000v initial setup

Posted by Peter Kurdziel on October 27, 2009

For installation see: 1000V demo video’s
Part 1 – VSM Install
http://vimeo.com/5719299
Part 2 – Connecting the VSM to vCenter
http://vimeo.com/5721462
Part 3 – Configuring Uplink Port Profiles
http://vimeo.com/5746855
Part – - Installing the VEM
http://vimeo.com/5792424

Connecting the Nexus 100v to Vmware virtual center:

N1KV-1# config t

N1KV-1(config)# svs conn vc
N1KV-1(config-svs-conn)# remote ip add 192.168.189.128 <— IP address of VCenter

N1KV-1(config-svs-conn)# protocol vmware-vim <— this is the only protocol available

N1KV-1(config-svs-conn)# vmware dvs datacenter-name DC <— the datacenter name
N1KV-1(config-svs-conn)# connect <——————-connect to Vcenter
Note: Command execution in progress..please wait

Configuring uplink port profiles:

N1KV-1# config t
N1KV-1(config)# port-Profile system-uplink
N1KV-1(config-port-prof)# sw mo tr
N1KV-1(config-port-prof)# sw tr all vlan add 51,52
N1KV-1(config-port-prof)# no shut
N1KV-1(config-port-prof)# channel-group auto sub-group cdp <– if you use multiple physical NICs.
 

N1KV-1(config-port-prof)# system vlan 51,52 <—add the control and packet vlans created in vsphere.

N1KV-1(config-port-prof)#
N1KV-1(config-port-prof)#
N1KV-1(config-port-prof)# capability uplink
N1KV-1(config-port-prof)#
N1KV-1(config-port-prof)#
N1KV-1(config-port-prof)#
N1KV-1(config-port-prof)# vmware port-group
N1KV-1(config-port-prof)#
N1KV-1(config-port-prof)# state enabled <— enable

N1KV-1(config)# vlan 53   <—- define a new vlan for VMs to use.
N1KV-1(config-vlan)# name VM-Data
N1KV-1(config-vlan)# exit
 
N1KV-1(config)# port-profile data-uplink < — for data traffic
N1KV-1(config-port-prof)# sw mo tr
N1KV-1(config-port-prof)# sw tr all vla add 53
N1KV-1(config-port-prof)# no shut

N1KV-1(config-port-prof)# channel-group auto sub-group cdp <– if you use multiple physical NICs.
N1KV-1(config-port-prof)#
N1KV-1(config-port-prof)#
N1KV-1(config-port-prof)# vmware port-group
N1KV-1(config-port-prof)# state enabled  <— pushes the port profile to the vcentr server
Note: Processing command..

N1KV-1(config)# port-profile Test-VM < —- for VM traffic
 
N1KV-1(config-port-prof)# sw mo acc
N1KV-1(config-port-prof)# sw acc vlan 53 <— defined earlier VM-Data traffic
N1KV-1(config-port-prof)# no shut
N1KV-1(config-port-prof)# vmware port-group
N1KV-1(config-port-prof)# tate enabled  <— pushes the port profile to the vcentr server
Note: Processing command..
N1KV-1(config-port-prof)# end

You will need to install the VEM – Virtual Ethernet Modules and install the vem code in vsphere.

Posted in Uncategorized | Leave a Comment »

show interfaces serial Status Line Conditions

Posted by Peter Kurdziel on March 22, 2009

show interfaces serial Status Line Conditions 

Status Line
Condition

Possible Problem

Solution

Serial x is up, line protocol is up

This is the proper status line condition. No action is required.

Serial x is down, line protocol is down (DTE1 mode)

The router is not sensing a CD2 signal (that is, the CD is not active).

A telephone company problem has occurred—line is down or is not connected to CSU3 /DSU4 .

Cabling is faulty or incorrect.

Hardware failure has occurred (CSU/DSU).

1. Check the LEDs on the CSU/DSU to see whether the CD is active, or insert a breakout box on the line to check for the CD signal.

2. Verify that you are using the proper cable and interface (see your hardware installation documentation).

3. Insert a breakout box and check all control leads.

4. Contact your leased-line or other carrier service to see whether there is a problem.

5. Swap faulty parts.

6. If you suspect faulty router hardware, change the serial line to another port. If the connection comes up, the previously connected interface has a problem.

Serial x is up, line protocol is down (DTE mode)

A local or remote router is misconfigured.

Keepalives are not being sent by the remote router.

A leased-line or other carrier service problem has occurred (noisy line or misconfigured or failed switch).

A timing problem has occurred on the cable (SCTE5 not set on CSU/DSU).

A local or remote CSU/DSU has failed.

Router hardware (local or remote) has failed.

1. Put the modem, CSU, or DSU in local loopback mode and use the show interfaces serial command to determine whether the line protocol comes up.

If the line protocol comes up, a telephone company problem or a failed remote router is the likely problem.

2. If the problem appears to be on the remote end, repeat Step 1 on the remote modem, CSU, or DSU.

3. Verify all cabling. Make certain that the cable is attached to the correct interface, the correct CSU/DSU, and the correct telephone company network termination point. Use the show controllers exec command to determine which cable is attached to which interface.

4. Enable the debug serial interface exec command.mmm ,,,,

Serial x is up, line protocol is down (DTE mode) (continued)

 

Caution: Because debugging output is assigned high priority in the CPU process, it can render the system unusable. For this reason, use debug commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff. Moreover, it is best to use debug commands during periods of lower network traffic and fewer users. Debugging during these periods decreases the likelihood that increased debug command processing overhead will affect system use.

5. If the line protocol does not come up in local loopback mode, and if the output of the debug serial interface exec command shows that the keepalive counter is not incrementing, a router hardware problem is likely. Swap router interface hardware.

6. If the line protocol comes up and the keepalive counter increments, the problem is not in the local router. Troubleshoot the serial line, as described in the sections “Troubleshooting Clocking Problems” and “CSU and DSU Loopback Tests,” later in this chapter.

7. If you suspect faulty router hardware, change the serial line to an unused port. If the connection comes up, the previously connected interface has a problem.

Serial x is up, line protocol is down (DCE6 mode)

The clockrate interface configuration command is missing.

The DTE device does not support or is not set up for SCTE mode (terminal timing).

The remote CSU or DSU has failed.

1. Add the clockrate interface configuration command on the serial interface.

Syntax:

clock rate bps

Syntax Description:

bps—Desired clock rate in bits per second: 1200, 2400, 4800, 9600, 19200, 38400, 56000, 64000, 72000, 125000, 148000, 250000, 500000, 800000, 1000000, 1300000, 2000000, 4000000, or 8000000.

Serial x is up, line protocol is down (DCE mode) (continued)

The clockrate interface configuration command is missing.

The DTE device does not support or is not set up for SCTE mode (terminal timing).

The remote CSU or DSU has failed.

2. Set the DTE device to SCTE modem if possible. If your CSU/DSU does not support SCTE, you might have to disable SCTE on the Cisco router interface. Refer to the section “Inverting the Transmit Clock,” later in this chapter.

3. Verify that the correct cable is being used.

4. If the line protocol is still down, there is a possible hardware failure or cabling problem. Insert a breakout box and observe leads.

5. Replace faulty parts, as necessary.

Serial x is up, line protocol is up (looped)

A loop exists in the circuit. The sequence number in the keepalive packet changes to a random number when a loop is initially detected. If the same random number is returned over the link, a loop exists.

1. Use the show running-config privileged exec command to look for any loopback interface configuration command entries.

2. If you find a loopback interface configuration command entry, use the no loopback interface configuration command to remove the loop.

3. If you do not find the loopback interface configuration command, examine the CSU/DSU to determine whether they are configured in manual loopback mode. If they are, disable manual loopback.

4. Reset the CSU or DSU, and inspect the line status. If the line protocol comes up, no other action is needed.

5. If the CSU or DSU is not configured in manual loopback mode, contact the leased-line or other carrier service for line troubleshooting assistance.

Serial x is up, line protocol is down (disabled)

A high error rate has occurred due to a telephone company service problem.

A CSU or DSU hardware problem has occurred.

Router hardware (interface) is bad.

1. Troubleshoot the line with a serial analyzer and breakout box. Look for toggling CTS7 and DSR8 signals.

2. Loop CSU/DSU (DTE loop). If the problem continues, it is likely that there is a hardware problem. If the problem does not continue, it is likely that there is a telephone company problem.

3. Swap out bad hardware, as required (CSU, DSU, switch, local or remote router).

Serial x is administrat-ively down, line protocol is down

The router configuration includes the shutdown interface configuration command.

A duplicate IP address exists.

1. Check the router configuration for the shutdown command.

2. Use the no shutdown interface configuration command to remove the shutdown command.

3. Verify that there are no identical IP addresses using the show running-config privileged exec command or the show interfaces exec command.

4. If there are duplicate addresses, resolve the conflict by changing one of the IP addresses.

1 DTE = data terminal equipment

2 CD = carrier detect

3 CSU = channel service unit

4 DSU = digital service unit

5 SCTE = serial clock transmit external

6 DCE = data circuit-terminating equipment or data communications equipment

7 CTS = clear-to-send

8 DSR = data-set ready

Posted in Other, Uncategorized | Leave a Comment »

Troubleshooting EIGRP

Posted by Peter Kurdziel on December 21, 2008

SEE http://www.ciscosystems.com/en/US/tech/tk365/technologies_tech_note09186a0080094613.shtml for interactive links.

IP Routing

Troubleshooting EIGRP

Document ID: 21324

<!–   –>


Interactive: This document offers customized analysis of your Cisco device.


Contents

Introduction
Prerequisites
Requirements
Components Used
Conventions
Main Troubleshooting Flowchart
Neighbor Check
Redistribution Check
Route Check
Reasons for Neighbor Flapping
EIGRP Neighbors are not Recognized
NetPro Discussion Forums – Featured Conversations
Related Information


Introduction

This document provides troubleshooting information for common problems with Enhanced Interior Gateway Routing Protocol (EIGRP). For more information, or to go to the next flowchart, refer to the links provided in this section.

If you have the output of a show interfaces serial , show ip eigrp neighbors , show tech-support , or a show ip eigrp topology command from your Cisco device, you can use Output Interpreter ( registered customers only) to display potential issues and fixes.

In order to use Output Interpreter, you must be a <a href=”http://www.cisco.com/register”>registered</a> customer, be logged in, and have JavaScript enabled.

Prerequisites

Requirements

Readers of this document should have a good understanding of how EIGRP works and a good knowledge of Configuring EIGRP.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Main Troubleshooting Flowchart

In order to troubleshoot EIGRP, use this flowchart, starting at the box marked Main. Depending on the symptoms, the flowchart might refer to one of the three flowcharts later in this document or to other relevant documents on Cisco.com. There are some problems that might not be resolvable here. In these cases, links are provided to Cisco Technical Support. In order to open a service request, you must have a valid service contract.

trouble_eigrp_01.gif

Neighbor Check

trouble_eigrp_02a.gif

Flowchart Notes
1 Issue the show ip eigrp interface command to verify.
2 Issue the show interface serial command to verify.

trouble_eigrp_02b.gif

Flowchart Notes
3 Issue the show ip interface command to verify.

Redistribution Check

trouble_eigrp_03.gif

Flowchart Notes
4 Issue the show ip eigrp topology net mask command to verify.

Route Check

trouble_eigrp_04a.gif

Flowchart Notes
5 Issue the show ip route eigrp command to verify.
6 Issue the show ip eigrp topology command to verify. If routes are not seen in the topology table, issue the clear ip eigrp topology command.

trouble_eigrp_04b.gif

Flowchart Notes
7 Issue the show ip eigrp topology net mask command, to find the Router ID (RID). You can find the local RID with the same command on the locally generated external router. In Cisco IOS Software Release 12.1 and later, the show ip eigrp topology command shows the RID.

Reasons for Neighbor Flapping

The stability of the neighbor relationship is of primary concern. A failure in the neighbor relationship is accompanied by increased CPU and bandwidth utilization. EIGRP neighbors can flap for these reasons:

  • Underlying link flaps. When an interface goes down, EIGRP takes down the neighbors that are reachable through that interface and flushes all routes learned through that neighbor.
  • Misconfigured hello and hold intervals. The EIGRP hold interval can be set independently of the hello interval if you issue the ip hold-time eigrp command. If you set a hold interval smaller than the hello interval, it results in the neighbors flapping continuously. Cisco recommends that the hold time be at least three times the hello interval. If the value is set less than 3 times the hello interval, there is the chance for link flapping or neighborship flapping.
  • Loss of hello packets: Hello packets can be lost on overly congested links or error-prone links (CRC errors, Frame errors, or excessive collisions).
  • Existence of unidirectional links. A router on a unidirectional link can be able to receive hello packets, but the hello packets sent out are not received at the other end. The existence of this state is usually indicated by the retry limit exceeded messages on one end. If the routers generating retry limit exceeded messages has to form neighborship, then make the link bidirectional for both unicast and multicast. In case tunnel interfaces are used in the topology make sure that the interfaces are advertised properly.
  • Route goes stuck-in-active. When a router enters the stuck-in-active state, the neighbors from which the reply was expected are reinitialized, and the router goes active on all routes learned from those neighbors.
  • Provision of insufficient bandwidth for the EIGRP process. When sufficient bandwidth is not available, packets can be lost, which causes neighbors to go down.
  • Bad serial lines.
  • Improperly set bandwidth statements.
  • One-way multicast traffic.
  • Stuck in active routes.
  • Query storms.

EIGRP Neighbors are not Recognized

The EIGRP neighbor relationship is not established over the multipoint GRE tunnel if there is an incorrect NHRP association in the spoke. Next Hop Resolution Protocol (NHRP) is used to discover the addresses of other routers and networks behind the routers that are connected to a nonbroadcast multiaccess (NBMA) network. When a network statement under Eigrp covers both the physical interface and tunnel interface (tunnel interface ip address and physical interface ip address belong to the same major class) and if the phyiscal interface is the source of the tunnel, then the both interfaces have to be separately advertised in the Eigrp to avoid issues with DMVPN. The best practice is to advertise the interfaces using specific subnet advertisements.

This issue can be resolved when you clear the NHRP associations with this command:

Router#clear ip nhrp

Posted in FRAME-RELAY, Routing & Switching Lab, Uncategorized | Leave a Comment »

IOS bug: ROM: 3600 Software (C3640-JK9O3S-M), Version 12.3(14)T7, RELEASE SOFTWARE (fc2)

Posted by Peter Kurdziel on November 5, 2008

Rack1SW2(config)#int range f1/7 , f1/9 , f1/10 – 11
Rack1SW2(config-if-range)#sw    <—– cmd didn’t take!!
Rack1SW2(config-if-range)#sw mo tr
Command rejected: Fa1/9 not a switching port.
Command rejected: Fa1/10 not a switching port.
Rack1SW2(config-if-range)#sw tr en dot
Command rejected: Fa1/9 not a switching port.
Command rejected: Fa1/10 not a switching port.
Rack1SW2(config-if-range)#
Rack1SW2(config-if-range)#int f1/9
Rack1SW2(config-if)#sw <— took it now.

Posted in Uncategorized | Leave a Comment »

Degugs

Posted by Peter Kurdziel on November 5, 2008

logging buffered <size>

no log console

:)

Posted in Uncategorized | Leave a Comment »

OSPF network types

Posted by Peter Kurdziel on October 26, 2008

http://www.cisco.com/en/US/docs/ios/12_0/np1/configuration/guide/1cospf.html#wp4739

Configure Your OSPF Network Type

You have the choice of configuring your OSPF network type as either broadcast or nonbroadcast multiaccess, regardless of the default media type. Using this feature, you can configure broadcast networks as nonbroadcast multiaccess networks when, for example, you have routers in your network that do not support multicast addressing. You also can configure nonbroadcast multiaccess networks (such as X.25, Frame Relay, and SMDS) as broadcast networks. This feature saves you from having to configure neighbors, as described in the section “Configure OSPF for Nonbroadcast Networks.”

Configuring nonbroadcast, multiaccess networks as either broadcast or nonbroadcast assumes that there are virtual circuits from every router to every router or fully meshed network. This is not true for some cases, for example, because of cost constraints, or when you have only a partially meshed network. In these cases, you can configure the OSPF network type as a point-to-multipoint network. Routing between two routers not directly connected will go through the router that has virtual circuits to both routers. Note that it is not necessary to configure neighbors when using this feature.

An OSPF point-to-multipoint interface is defined as a numbered point-to-point interface having one or more neighbors. It creates multiple host routes. An OSPF point-to-multipoint network has the following benefits compared to nonbroadcast multiaccess and point-to-point networks:

Point-to-multipoint is easier to configure because it requires no configuration of neighbor commands, it consumes only one IP subnet, and it requires no designated router election.

It costs less because it does not require a fully meshed topology.

It is more reliable because it maintains connectivity in the event of virtual circuit failure.

To configure your OSPF network type, use the following command in interface configuration mode:

Command

Purpose

ip ospf network {broadcast | non-broadcast | {point-to-multipoint [non-broadcast] }}

Configure the OSPF network type for a specified interface.

See the “OSPF Point-to-Multipoint Example” section at the end of this chapter for an example of an OSPF point-to-multipoint network.

Configure Point-to-Multipoint, Broadcast Networks

On point-to-multipoint, broadcast networks, there is no need to specify neighbors. However, you can specify neighbors with the neighbor command, in which case you should specify a cost to that neighbor.

Before this feature, some OSPF point-to-multipoint protocol traffic was treated as multicast traffic. Therefore, the neighbor command was not needed for point-to-multipoint interfaces because multicast took care of the traffic. Hellos, updates and acknowledgments were sent using multicast. In particular, multicast hellos discovered all neighbors dynamically.

On any point-to-multipoint interface (broadcast or not), the Cisco IOS software assumed the cost to each neighbor was equal. The cost was configured with the ip ospf cost command. In reality, the bandwidth to each neighbor is different, so the cost should be different. With this feature, you can configure a separate cost to each neighbor. This feature applies to point-to-multipoint interfaces only.

To treat an interface as point-to-multipoint broadcast and assign a cost to each neighbor, use the following commands beginning in interface configuration mode:

Step

Command

Purpose

1

ip ospf network point-to-multipoint

Configure an interface as point-to-multipoint for broadcast media.

2

exit

Enter global configuration mode.

3

router ospf process-id

Configure an OSPF routing process and enter router configuration mode.

4

neighbor ip-address cost number

Specify a neighbor and assign a cost to the neighbor.

5

Repeat Step 4 for each neighbor if you want to specify a cost. Otherwise, neighbors will assume the cost of the interface, based on the ip ospf cost command.

Configure OSPF for Nonbroadcast Networks

Because there might be many routers attached to an OSPF network, a designated router is selected for the network. It is necessary to use special configuration parameters in the designated router selection if broadcast capability is not configured.

These parameters need only be configured in those devices that are themselves eligible to become the designated router or backup designated router (in other words, routers with a nonzero router priority value).

To configure routers that interconnect to nonbroadcast networks, use the following command in router configuration mode:

Command

Purpose

neighbor ip-address [priority number] [poll-interval seconds]

Configure a router interconnecting to nonbroadcast networks.

You can specify the following neighbor parameters, as required:

Priority for a neighboring router

Nonbroadcast poll interval

Interface through which the neighbor is reachable

On point-to-multipoint, nonbroadcast networks, you now use the neighbor command to identify neighbors. Assigning a cost to a neighbor is optional.

Prior to Release 12.0, some customers were using point-to-multipoint on nonbroadcast media (such as classic IP over ATM), so their routers could not dynamically discover their neighbors. This feature allows the neighbor command to be used on point-to-multipoint interfaces.

On any point-to-multipoint interface (broadcast or not), the Cisco IOS software assumed the cost to each neighbor was equal. The cost was configured with the ip ospf cost command. In reality, the bandwidth to each neighbor is different, so the cost should be different. With this feature, you can configure a separate cost to each neighbor. This feature applies to point-to-multipoint interfaces only.

To treat the interface as point-to-multipoint when the media does not support broadcast, use the following commands beginning in interface configuration mode:

Step

Command

Purpose

1

ip ospf network point-to-multipoint non-broadcast

Configure an interface as point-to-multipoint for nonbroadcast media.

2

exit

Enter global configuration mode.

3

router ospf process-id

Configure an OSPF routing process and enter router configuration mode.

4

neighbor ip-address [cost number]

Specify an OSPF neighbor and optionally assign a cost to the neighbor.

5

Repeat Step 4 for each neighbor.

See–>  http://packetlife.net/static/cheatsheets/ospf.pdf
NETWORK TYPES

Nonbroadcast     –   (NBMA)

DR/BDR  Eelected               YES
Neighbor Discovery            NO
Hello/Dead Timers             30/120
Standard                             RFC 2328
Supported Technology        FULL MESH

Multipoint   – Broadcast

DR/BDR  Eelected            NO
Neighbor Discovery        YES
Hello/Dead Timers         30/120
Standard                         RFC 2328
Supported Technology    ANY
Multipoint – Nonbroadcast

DR/BDR  Eelected             NO
Neighbor Discovery         NO
Hello/Dead Timers          30/120
Standard                          CISCO
Supported Technology    ANY

Broadcast

DR/BDR  Eelected             YES
Neighbor Discovery         YES
Hello/Dead Timers          10/1940
Standard                          CISCO
Supported Technology    FULL MESH

Point-to-Point

DR/BDR  Eelected                NO
Neighbor Discovery            YES – multicast hello’s
Hello/Dead Timers             10/1940
Standard                             CISCO
Supported Technology        POINT-TO-POINT

Posted in Uncategorized | Leave a Comment »

OSPF commands

Posted by Peter Kurdziel on October 26, 2008

sh ip ospf ?
<1-65535>            Process ID number
border-routers       Border and Boundary Router Information
database             Database summary
flood-list           Link state flood list
interface            Interface information
max-metric           Max-metric origination information
mpls                 MPLS related information
neighbor             Neighbor list
request-list         Link state request list
retransmission-list  Link state retransmission list
sham-links           Sham link information
statistics           Various OSPF Statistics
summary-address      Summary-address redistribution Information
timers               OSPF timers information
traffic              Traffic related statistics
virtual-links        Virtual link information
|                    Output modifiers

debug ip ospf ?
adj             OSPF adjacency events
database-timer  OSPF database timer
events          OSPF events
flood           OSPF flooding
hello           OSPF hello events
lsa-generation  OSPF lsa generation
mpls            OSPF MPLS
nsf             OSPF non-stop forwarding events
packet          OSPF packets
retransmission  OSPF retransmission events
spf             OSPF spf
tree            OSPF database tree

sh ip ospf int brief

Posted in Uncategorized | Leave a Comment »

OSPF – 2 ways to enable the ospf process on an interface.

Posted by Peter Kurdziel on October 26, 2008

  1. the network statement under the routing process.
  2. ip ospf [process-id] area [area-id] at the interface level.

Posted in Uncategorized | Leave a Comment »

EIGRP ways to advertise a default route

Posted by Peter Kurdziel on October 18, 2008

ip default-net  200.00.00.00

ip summ ei 1 0.0.0.0 0.0.0.0 <— with this all the previously advertised routes will be surpressed since all networks are a subnet of 0.0.0.0/0

 

From cisco.com

There are two ways to inject a default route into EIGRP: redistribute a static route or summarize to 0.0.0.0/0. Use the first method when you want to draw all traffic to unknown destinations to a default route at the core of the network. This method is effective for advertising connections to the Internet. For example:

ip route 0.0.0.0 0.0.0.0 x.x.x.x (next hop to the internet)
!
router eigrp 100
 redistribute static
 default-metric 10000 1 255 1 1500

The static route that is redistributed into EIGRP does not have to be to network 0.0.0.0. If you use another network, you must use the ip default-network command to mark the network as a default network. Refer to Configuring a Gateway of Last Resort for further information.

Summarizing to a default route is effective only when you want to provide remote sites with a default route. Since summaries are configured per interface, you do not need to worry about using distribute-lists or other mechanisms to prevent the default route from being propagated toward the core of your network. Note that a summary to 0.0.0.0/0 overrides a default route learned from any other routing protocol. The only way to configure a default route on a router using this method is to configure a static route to 0.0.0.0/0. (Beginning in Cisco IOS Software 12.0(4)T, you can also configure an administrative distance on the end of the summary-address command, so the local summary does not override the 0.0.0.0/0 route).

router eigrp 100
 network 10.0.0.0
!
interface serial 0
 encapsulation frame-relay
 no ip address
!
interface serial 0.1 point-to-point
 ip address 10.1.1.1
 frame-relay interface-dlci 10
 ip summary-address eigrp 100 0.0.0.0 0.0.0.0

Posted in Uncategorized | Tagged: | Leave a Comment »

Dual boot XP/Linux

Posted by Peter Kurdziel on October 15, 2008

http://apcmag.com/how_to_dual_boot_windows_xp_and_linux_xp_installed_first.htm

Posted in Uncategorized | Leave a Comment »