Top 5 Free Resume Hosting Websites

Afraid of the pink slip? Keep your online resume hosted for free on these cool websites.

There are dozens of resume building websites offering a combination of free and paid services. Many sites have excellent resume building tools, a wide variety of templates and formatting options, but do not allow you to host your resume with a personalized URL for free. From this crowd, we have distilled those sites that allow you to host your online resumes for free.

EMurse

This site allows you to create your resume in sections, and choose a design from many different templates. The resumes are suited for more conventional formats. The exclusive feature of this site is that you can publicize one URL for your resume from where employers can download your resume in various formats such as DOC, PDF, RTF, etc. Read more about EMurse in our previous coverage here.

Visual CV

Visual CV allows you to create multiple online resumes easily, with a variety of different templates. You can directly import your LinkedIn profile to jump-start resume creation, and easily incorporate multimedia elements in your portfolio. Read more about Visual CV in our previous coverage here.

Lead You

This site is geared towards artists and other creative professionals looking for a snazzy online resume. It has a wide variety of templates, and allows you to attach documents, presentations, video and audio clips to your portfolio.

How To Write A Resume.Net

This is a clean site with simple resume building tools. The unique feature of this site is the ‘Headline Helper’, which allows you to tweak the Objective/Summary sections of your resume.

If you are stuck for words, this is a great tool. The free option allows only the basic template and HTML/text download, other options require a membership.

My Resume Online

For those looking for a minimalist Google-like interface, My Resume Online offers a barebones but fully functional and free solution. You can attach your photo, MS Office documents (including Access databases), PDF, and GIF/JPG images to your resume.

Understanding Redistribution (Part II)

Simple Redistribution Step-by-Step

We’re going to take our basic topology from the previous post Understanding Redistribution Part I , and configure to provide full connectivity between all devices with the most simple configuration. Then we are going to tweak some settings and see how they affect redistribution and optimal routing. This is going to be an introductory example to illustrate the redistribution control techniques mentioned previously.

First, we configure IGP routing per the diagram, and advertise Loopback0 interfaces (150.X.Y.Y/24, where X is the rack number, and Y is the router number) into IGP. Specifically, R2, R3 and R4 Loopbacks are advertised into OSPF Area 0. R5 and R6 Loopbacks are advertised into EIGRP 356 and R1 Loopback interface is simply advertised into EIGRP 123.

Next, we propose OSPF to be the core routing domain, used as transit path to reach any other domains. All other domains, in effect, will be connected as stub (non-transit) to the core domain. We start with EIGRP 123 and OSPF domains, and enable mutual redistribution between them on R2 and R3 routers:

R2: ! ! Metric values are chosen just to be easy to type in ! No big secret rules of thumb behind this one ! router eigrp 123  redistribute ospf 1 metric 1 1 1 1 1 ! router ospf 1  redistribute eigrp 123 subnets  R3: router eigrp 123  redistribute ospf 1 metric 1 1 1 1 1 ! router ospf 1  redistribute eigrp 123 subnets 

In effect, we would expect both routing domains to become transit for each other. However, EIGRP has a really nice feature of assigning default AD value of 170 to external routes. This, in turn, prevents circular redistribution - all OSPF routes injected into EIGRP 123 domain have AD of 170, and are effectively stopped from being advertised back into OSPF, since native OSPF routes preempt them. Let’s see the routing table states:

Rack18R1#show ip route eigrp      174.18.0.0/24 is subnetted, 2 subnets D EX    174.18.234.0            [170/2560002816] via 174.18.123.3, 00:02:03, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:02:03, FastEthernet0/0      150.18.0.0/24 is subnetted, 4 subnets D EX    150.18.4.0            [170/2560002816] via 174.18.123.3, 00:02:03, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:02:03, FastEthernet0/0 D EX    150.18.2.0            [170/2560002816] via 174.18.123.3, 00:02:03, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:02:03, FastEthernet0/0 D EX    150.18.3.0            [170/2560002816] via 174.18.123.3, 00:02:03, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:02:03, FastEthernet0/0 

Just as we would expect, R1 has two routes from each OSPF prefix, since both R2 and R3 assign the same seed metric to redistributed routes.

Rack18R2#show ip route | beg Gate Gateway of last resort is not set       174.18.0.0/24 is subnetted, 2 subnets C       174.18.234.0 is directly connected, Serial0/0 C       174.18.123.0 is directly connected, FastEthernet0/0      150.18.0.0/24 is subnetted, 4 subnets O       150.18.4.0 [110/65] via 174.18.234.4, 00:00:19, Serial0/0 D       150.18.1.0 [90/156160] via 174.18.123.1, 00:00:13, FastEthernet0/0 C       150.18.2.0 is directly connected, Loopback0 O       150.18.3.0 [110/65] via 174.18.234.3, 00:00:19, Serial0/0  Rack18R3#show ip route  | beg Gate Gateway of last resort is not set       174.18.0.0/24 is subnetted, 3 subnets C       174.18.234.0 is directly connected, Serial1/0 C       174.18.0.0 is directly connected, FastEthernet0/1 C       174.18.123.0 is directly connected, FastEthernet0/0      150.18.0.0/24 is subnetted, 6 subnets O       150.18.4.0 [110/782] via 174.18.234.4, 00:00:54, Serial1/0 D       150.18.5.0 [90/156160] via 174.18.0.5, 00:17:51, FastEthernet0/1 D       150.18.6.0 [90/156160] via 174.18.0.6, 00:17:49, FastEthernet0/1 D       150.18.1.0 [90/156160] via 174.18.123.1, 00:00:48, FastEthernet0/0 O       150.18.2.0 [110/782] via 174.18.234.2, 00:00:54, Serial1/0 C       150.18.3.0 is directly connected, Loopback0 

All seems to be fine here too; thanks to EIGRP AD value of 90, EIGRP “native” prefixes are reachable via EIGRP, and OSPF native subnets are reachable via OSPF (since EIGRP External AD value is 170). Next, we move a step further, and redistribute between OSPF and EIGRP 356 domains, i.e. attach the latter domain to the “core”:

R3: router eigrp 356  redistribute ospf 1 metric 1 1 1 1 1 ! router ospf 1  redistribute eigrp 123 subnets  redistribute eigrp 356 subnets 

Since EIGRP 356 domain has just one point of attachement to the core, there should be no big problems. Look at the routing table of R1:

Rack18R1#show ip route eigrp      174.18.0.0/24 is subnetted, 3 subnets D EX    174.18.234.0            [170/2560002816] via 174.18.123.3, 00:05:52, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:05:52, FastEthernet0/0 D EX    174.18.0.0            [170/2560002816] via 174.18.123.2, 00:01:36, FastEthernet0/0      150.18.0.0/24 is subnetted, 6 subnets D EX    150.18.4.0            [170/2560002816] via 174.18.123.3, 00:05:52, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:05:52, FastEthernet0/0 D EX    150.18.5.0            [170/2560002816] via 174.18.123.2, 00:01:36, FastEthernet0/0 D EX    150.18.6.0            [170/2560002816] via 174.18.123.2, 00:01:36, FastEthernet0/0 D EX    150.18.2.0            [170/2560002816] via 174.18.123.3, 00:05:52, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:05:52, FastEthernet0/0 D EX    150.18.3.0            [170/2560002816] via 174.18.123.3, 00:05:52, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:05:52, FastEthernet0/0 

Ah, great. R1 sees R5 and R6 loopback as they are advertised by R2 only. Naturally, redistribution between local routing processes on R3 is non-transitive - when we inject EIGRP 356 routes into OSPF, they are not further propagated into EIGRP 123, even though OSPF is redistributed into EIGRP 123. So R1 packets would have to transit OSPF domain, in order to reach R5 and R6.

R2 sees EIGRP 356 routes reachable via R3:

Rack18R2#show ip route | beg Gate Gateway of last resort is not set       174.18.0.0/24 is subnetted, 3 subnets C       174.18.234.0 is directly connected, Serial0/0 O E2    174.18.0.0 [110/20] via 174.18.234.3, 00:02:20, Serial0/0 C       174.18.123.0 is directly connected, FastEthernet0/0      150.18.0.0/24 is subnetted, 6 subnets O       150.18.4.0 [110/65] via 174.18.234.4, 00:06:41, Serial0/0 O E2    150.18.5.0 [110/20] via 174.18.234.3, 00:02:20, Serial0/0 O E2    150.18.6.0 [110/20] via 174.18.234.3, 00:02:20, Serial0/0 D       150.18.1.0 [90/156160] via 174.18.123.1, 00:06:35, FastEthernet0/0 C       150.18.2.0 is directly connected, Loopback0 O       150.18.3.0 [110/65] via 174.18.234.3, 00:06:41, Serial0/0 

And R3 in turn sees them as EIGRP 356 native ones:

Rack18R3#show ip route | beg Gate Gateway of last resort is not set       174.18.0.0/24 is subnetted, 3 subnets C       174.18.234.0 is directly connected, Serial1/0 C       174.18.0.0 is directly connected, FastEthernet0/1 C       174.18.123.0 is directly connected, FastEthernet0/0      150.18.0.0/24 is subnetted, 6 subnets O       150.18.4.0 [110/782] via 174.18.234.4, 00:02:47, Serial1/0 D       150.18.5.0 [90/156160] via 174.18.0.5, 00:02:36, FastEthernet0/1 D       150.18.6.0 [90/156160] via 174.18.0.6, 00:02:36, FastEthernet0/1 D       150.18.1.0 [90/156160] via 174.18.123.1, 00:02:34, FastEthernet0/0 O       150.18.2.0 [110/782] via 174.18.234.2, 00:02:47, Serial1/0 C       150.18.3.0 is directly connected, Loopback0 

Fine, now to finish the picture, we redistribute between RIP and OSPF on R4

R4: router ospf 1  redistribute rip subnets ! ! Assign some large metric value to redistributed routes ! router rip  redistribute ospf 1 metric 8 

Check to see the full routing table of R1:

Rack18R1#show ip route eigrp D EX 222.22.2.0/24            [170/2560002816] via 174.18.123.3, 00:02:16, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:02:16, FastEthernet0/0 D EX 220.20.3.0/24            [170/2560002816] via 174.18.123.3, 00:02:16, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:02:16, FastEthernet0/0      174.18.0.0/24 is subnetted, 3 subnets D EX    174.18.234.0            [170/2560002816] via 174.18.123.3, 00:05:17, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:05:17, FastEthernet0/0 D EX    174.18.0.0            [170/2560002816] via 174.18.123.2, 00:08:33, FastEthernet0/0 D EX 192.10.18.0/24            [170/2560002816] via 174.18.123.3, 00:02:16, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:02:16, FastEthernet0/0      150.18.0.0/24 is subnetted, 6 subnets D EX    150.18.4.0            [170/2560002816] via 174.18.123.3, 00:05:17, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:05:17, FastEthernet0/0 D EX    150.18.5.0            [170/2560002816] via 174.18.123.2, 00:05:14, FastEthernet0/0 D EX    150.18.6.0            [170/2560002816] via 174.18.123.2, 00:05:15, FastEthernet0/0 D EX    150.18.2.0            [170/2560002816] via 174.18.123.3, 00:05:20, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:05:20, FastEthernet0/0 D EX    150.18.3.0            [170/2560002816] via 174.18.123.3, 00:05:20, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:05:20, FastEthernet0/0 D EX 205.90.31.0/24            [170/2560002816] via 174.18.123.3, 00:02:19, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:02:19, FastEthernet0/0 

Seems like we have connectivity to all prefixes, even the ones injected by BB2 (205.90.31.0/24 etc). All of them, with except to EIGRP 356 routes are symmetrically reachable via R2 and R3. Now, a long snapshot of all other routing tables:

Rack18R2#show ip route | beg Gate Gateway of last resort is not set  O E2 222.22.2.0/24 [110/20] via 174.18.234.4, 00:03:29, Serial0/0 O E2 220.20.3.0/24 [110/20] via 174.18.234.4, 00:03:29, Serial0/0      174.18.0.0/24 is subnetted, 3 subnets C       174.18.234.0 is directly connected, Serial0/0 O E2    174.18.0.0 [110/20] via 174.18.234.3, 00:03:29, Serial0/0 C       174.18.123.0 is directly connected, FastEthernet0/0 O E2 192.10.18.0/24 [110/20] via 174.18.234.4, 00:03:29, Serial0/0      150.18.0.0/24 is subnetted, 6 subnets O       150.18.4.0 [110/65] via 174.18.234.4, 00:03:29, Serial0/0 O E2    150.18.5.0 [110/20] via 174.18.234.3, 00:03:29, Serial0/0 O E2    150.18.6.0 [110/20] via 174.18.234.3, 00:03:29, Serial0/0 D       150.18.1.0 [90/156160] via 174.18.123.1, 00:19:36, FastEthernet0/0 C       150.18.2.0 is directly connected, Loopback0 O       150.18.3.0 [110/65] via 174.18.234.3, 00:03:29, Serial0/0 O E2 205.90.31.0/24 [110/20] via 174.18.234.4, 00:03:29, Serial0/0  Rack18R3#show ip route | beg Gate Gateway of last resort is not set  O E2 222.22.2.0/24 [110/20] via 174.18.234.4, 00:03:56, Serial1/0 O E2 220.20.3.0/24 [110/20] via 174.18.234.4, 00:03:56, Serial1/0      174.18.0.0/24 is subnetted, 3 subnets C       174.18.234.0 is directly connected, Serial1/0 C       174.18.0.0 is directly connected, FastEthernet0/1 C       174.18.123.0 is directly connected, FastEthernet0/0 O E2 192.10.18.0/24 [110/20] via 174.18.234.4, 00:03:56, Serial1/0      150.18.0.0/24 is subnetted, 6 subnets O       150.18.4.0 [110/782] via 174.18.234.4, 00:03:56, Serial1/0 D       150.18.5.0 [90/156160] via 174.18.0.5, 00:06:58, FastEthernet0/1 D       150.18.6.0 [90/156160] via 174.18.0.6, 00:06:58, FastEthernet0/1 D       150.18.1.0 [90/156160] via 174.18.123.1, 00:06:57, FastEthernet0/0 O       150.18.2.0 [110/782] via 174.18.234.2, 00:03:56, Serial1/0 C       150.18.3.0 is directly connected, Loopback0 O E2 205.90.31.0/24 [110/20] via 174.18.234.4, 00:03:56, Serial1/0  Rack18R4#show ip route | beg Gate Gateway of last resort is not set  R    222.22.2.0/24 [120/7] via 192.10.18.254, 00:00:19, FastEthernet0/0 R    220.20.3.0/24 [120/7] via 192.10.18.254, 00:00:19, FastEthernet0/0      174.18.0.0/24 is subnetted, 3 subnets C       174.18.234.0 is directly connected, Serial0/0 O E2    174.18.0.0 [110/20] via 174.18.234.3, 00:05:11, Serial0/0 O E2    174.18.123.0 [110/20] via 174.18.234.3, 00:05:11, Serial0/0                      [110/20] via 174.18.234.2, 00:05:11, Serial0/0 C    192.10.18.0/24 is directly connected, FastEthernet0/0      150.18.0.0/24 is subnetted, 6 subnets C       150.18.4.0 is directly connected, Loopback0 O E2    150.18.5.0 [110/20] via 174.18.234.3, 00:05:11, Serial0/0 O E2    150.18.6.0 [110/20] via 174.18.234.3, 00:05:11, Serial0/0 O E2    150.18.1.0 [110/20] via 174.18.234.3, 00:05:11, Serial0/0                    [110/20] via 174.18.234.2, 00:05:11, Serial0/0 O       150.18.2.0 [110/65] via 174.18.234.2, 00:05:11, Serial0/0 O       150.18.3.0 [110/65] via 174.18.234.3, 00:05:11, Serial0/0 R    205.90.31.0/24 [120/7] via 192.10.18.254, 00:00:20, FastEthernet0/0 

A quick stop at R5. Since RIPv2 AD is 120, and EIGRP External AD is 170, R5 sees all non EIGRP 356 routes via RIP. Not a big problem right now, but it creates “suboptimal” paths to EIGRP 123 routes, since it’s more, well, effective to reach them over Ethernet links.

Rack18R5#sh ip route | beg Gate Gateway of last resort is not set  R    222.22.2.0/24 [120/7] via 192.10.18.254, 00:00:25, FastEthernet0/1 R    220.20.3.0/24 [120/7] via 192.10.18.254, 00:00:25, FastEthernet0/1      174.18.0.0/24 is subnetted, 3 subnets R       174.18.234.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1 C       174.18.0.0 is directly connected, FastEthernet0/0 R       174.18.123.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1 C    192.10.18.0/24 is directly connected, FastEthernet0/1      150.18.0.0/24 is subnetted, 6 subnets R       150.18.4.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1 C       150.18.5.0 is directly connected, Loopback0 D       150.18.6.0 [90/156160] via 174.18.0.6, 00:43:41, FastEthernet0/0 R       150.18.1.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1 R       150.18.2.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1 R       150.18.3.0 [120/8] via 192.10.18.4, 00:00:04, FastEthernet0/1 R    205.90.31.0/24 [120/7] via 192.10.18.254, 00:00:25, FastEthernet0/1 

We may opt to craeate an access-list, select all RIP routes, and freeze their AD down to 120. Next we can rais global RIP distance to something bigger than 170, to fix this issue. Not a big deal, though! OK, so the only left are R6 and BB2:

Rack18R6#show ip route eigrp D EX 222.22.2.0/24 [170/2560002816] via 174.18.0.3, 00:07:29, FastEthernet0/0 D EX 220.20.3.0/24 [170/2560002816] via 174.18.0.3, 00:07:29, FastEthernet0/0      174.18.0.0/24 is subnetted, 2 subnets D EX    174.18.234.0            [170/2560002816] via 174.18.0.3, 00:10:31, FastEthernet0/0 D EX 192.10.18.0/24 [170/2560002816] via 174.18.0.3, 00:07:29, FastEthernet0/0      150.18.0.0/24 is subnetted, 5 subnets D EX    150.18.4.0 [170/2560002816] via 174.18.0.3, 00:10:31, FastEthernet0/0 D       150.18.5.0 [90/156160] via 174.18.0.5, 00:41:30, FastEthernet0/0 D EX    150.18.2.0 [170/2560002816] via 174.18.0.3, 00:10:31, FastEthernet0/0 D EX    150.18.3.0 [170/2560002816] via 174.18.0.3, 00:10:31, FastEthernet0/0 D EX 205.90.31.0/24 [170/2560002816] via 174.18.0.3, 00:07:29, FastEthernet0/0  BB2>sh ip ro rip      174.18.0.0/24 is subnetted, 3 subnets R       174.18.234.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0 R       174.18.0.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0 R       174.18.123.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0      150.18.0.0/24 is subnetted, 6 subnets R       150.18.4.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0 R       150.18.5.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0 R       150.18.6.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0 R       150.18.1.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0 R       150.18.2.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0 R       150.18.3.0 [120/8] via 192.10.18.4, 00:00:24, Ethernet0 

This seems to be an easy one. We’re done, full connectivity attained, and no loops were introduced. Thanks to EIGRP External AD there is no need to manually filter routes on the border routes between EIGRP 123 and OSPF. But what if we are asked to redistribute some “native” EIGRP 123 prefixes (e.g. R1 Loopback0) instead of advertising them?

R1: router eigrp 123  redistribute connected  network 174.18.123.1 0.0.0.0 

See what happens:

Rack18R2#show ip route | beg Gate Gateway of last resort is not set  O E2 222.22.2.0/24 [110/20] via 174.18.234.4, 00:15:13, Serial0/0 O E2 220.20.3.0/24 [110/20] via 174.18.234.4, 00:15:13, Serial0/0      174.18.0.0/24 is subnetted, 3 subnets C       174.18.234.0 is directly connected, Serial0/0 O E2    174.18.0.0 [110/20] via 174.18.234.3, 00:15:13, Serial0/0 C       174.18.123.0 is directly connected, FastEthernet0/0 O E2 192.10.18.0/24 [110/20] via 174.18.234.4, 00:15:13, Serial0/0      150.18.0.0/24 is subnetted, 6 subnets O       150.18.4.0 [110/65] via 174.18.234.4, 00:15:13, Serial0/0 O E2    150.18.5.0 [110/20] via 174.18.234.3, 00:15:13, Serial0/0 O E2    150.18.6.0 [110/20] via 174.18.234.3, 00:15:13, Serial0/0 D EX    150.18.1.0 [170/156160] via 174.18.123.1, 00:01:49, FastEthernet0/0 C       150.18.2.0 is directly connected, Loopback0 O       150.18.3.0 [110/65] via 174.18.234.3, 00:15:13, Serial0/0 O E2 205.90.31.0/24 [110/20] via 174.18.234.4, 00:15:13, Serial0/0 

R2 sees R1 Loopback0 as EIGRP external route reachable via R1. However, the situation is different on R3:

Rack18R3#show ip route | beg Gate Gateway of last resort is not set  O E2 222.22.2.0/24 [110/20] via 174.18.234.4, 00:16:10, Serial1/0 O E2 220.20.3.0/24 [110/20] via 174.18.234.4, 00:16:10, Serial1/0      174.18.0.0/24 is subnetted, 3 subnets C       174.18.234.0 is directly connected, Serial1/0 C       174.18.0.0 is directly connected, FastEthernet0/1 C       174.18.123.0 is directly connected, FastEthernet0/0 O E2 192.10.18.0/24 [110/20] via 174.18.234.4, 00:16:10, Serial1/0      150.18.0.0/24 is subnetted, 6 subnets O       150.18.4.0 [110/782] via 174.18.234.4, 00:16:10, Serial1/0 D       150.18.5.0 [90/156160] via 174.18.0.5, 00:19:12, FastEthernet0/1 D       150.18.6.0 [90/156160] via 174.18.0.6, 00:19:12, FastEthernet0/1 O E2    150.18.1.0 [110/20] via 174.18.234.2, 00:02:46, Serial1/0 O       150.18.2.0 [110/782] via 174.18.234.2, 00:16:10, Serial1/0 C       150.18.3.0 is directly connected, Loopback0 O E2 205.90.31.0/24 [110/20] via 174.18.234.4, 00:16:10, Serial1/0 

Thanks to R1 Loopback0 being redistributed into OSPF, R3 prefers it via R2, not R1, due to AD values. Not a very big problem in this scenario, but in more complex cases this may lead to routing loops, since suboptimal path may be chosen. In order to fix this, we may adjust AD for the EIGRP prefix. However, there is a problem here - we can’t change EIGRP external AD selectively, only for all prefixes at once.

This why we may choose to play with AD under OSPF. We may simply adjust AD for R1 Loopback0 prefix to a value of 171. However, we may go further, and simulate the feature of EIGRP with OSPF - speficically, make sure OSPF internal routes have AD different from the external prefixes. For EIGRP the values are 90 and 170. What values should we pick up for OSPF? Well, since OSPF is the core routing domain, it has more information available on what’s going around. Okay, and it’s the only transit domain, so we should make sure it has the highest preference among others. So it makes sense to set internal/external AD for OSPF to 80 and 160 - lower than the EIGRP values. This ensure that internal routes are always preferred over external, but core routing protocol is always the most trusted one.

R2 & R3: access-list 1 permit 150.18.1.0 ! router ospf 1 distance ospf intra-area 80 distance ospf inter-area 80 distance ospf external 160 distance 171 0.0.0.0 255.255.255.255 1 

See how this works on R2 and R3:

Rack18R2#show ip route | beg Gate Gateway of last resort is not set  O E2 222.22.2.0/24 [160/20] via 174.18.234.4, 00:00:07, Serial0/0 O E2 220.20.3.0/24 [160/20] via 174.18.234.4, 00:00:07, Serial0/0      174.18.0.0/24 is subnetted, 3 subnets C       174.18.234.0 is directly connected, Serial0/0 O E2    174.18.0.0 [160/20] via 174.18.234.3, 00:00:35, Serial0/0 C       174.18.123.0 is directly connected, FastEthernet0/0 O E2 192.10.18.0/24 [160/20] via 174.18.234.4, 00:00:35, Serial0/0      150.18.0.0/24 is subnetted, 6 subnets O       150.18.4.0 [80/65] via 174.18.234.4, 00:00:35, Serial0/0 O E2    150.18.5.0 [160/20] via 174.18.234.3, 00:00:35, Serial0/0 O E2    150.18.6.0 [160/20] via 174.18.234.3, 00:00:35, Serial0/0 D EX    150.18.1.0 [170/156160] via 174.18.123.1, 00:03:10, FastEthernet0/0 C       150.18.2.0 is directly connected, Loopback0 O       150.18.3.0 [80/65] via 174.18.234.3, 00:00:35, Serial0/0 O E2 205.90.31.0/24 [160/20] via 174.18.234.4, 00:00:07, Serial0/0 

OK, just as it was before, next comes R3:

Rack18R3#show ip route | beg Gate Gateway of last resort is not set  O E2 222.22.2.0/24 [160/20] via 174.18.234.4, 00:00:55, Serial1/0 O E2 220.20.3.0/24 [160/20] via 174.18.234.4, 00:00:55, Serial1/0      174.18.0.0/24 is subnetted, 3 subnets C       174.18.234.0 is directly connected, Serial1/0 C       174.18.0.0 is directly connected, FastEthernet0/1 C       174.18.123.0 is directly connected, FastEthernet0/0 O E2 192.10.18.0/24 [160/20] via 174.18.234.4, 00:01:14, Serial1/0      150.18.0.0/24 is subnetted, 6 subnets O       150.18.4.0 [80/782] via 174.18.234.4, 00:01:14, Serial1/0 D       150.18.5.0 [90/156160] via 174.18.0.5, 00:37:14, FastEthernet0/1 D       150.18.6.0 [90/156160] via 174.18.0.6, 00:37:14, FastEthernet0/1 D EX    150.18.1.0 [170/156160] via 174.18.123.1, 00:03:58, FastEthernet0/0 O       150.18.2.0 [80/782] via 174.18.234.2, 00:01:14, Serial1/0 C       150.18.3.0 is directly connected, Loopback0 O E2 205.90.31.0/24 [160/20] via 174.18.234.4, 00:00:56, Serial1/0 

All seems to look great, with except to the fact that EIGRP 123 and EIGRP 356 have to transit OSPF domain in order to reach each other. Though this is only true for R1, still we need to find out a way to resolve this issue. What if we start exhanging routes on R3 between EIGRP 123 and EIGRP 356? This will not cause any new domain to become transit - because EIGRP external AD will block the external routes from being re-injected into the core domain. This is why we may safely turn on mutual redistribution between the two domains.

R3: router eigrp 123  redistribute eigrp 356 ! router eigrp 356  redistribute eigrp 123 

Observe the effect on R1 now. Note the metrics assigned to R5 and R6 Loopback prefixes - they are taken directly from EIGRP 356 native prefixe metric values.

Rack18R1#show ip route eigrp D EX 222.22.2.0/24            [170/2560002816] via 174.18.123.3, 00:20:05, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:20:05, FastEthernet0/0 D EX 220.20.3.0/24            [170/2560002816] via 174.18.123.3, 00:20:05, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:20:05, FastEthernet0/0      174.18.0.0/24 is subnetted, 3 subnets D EX    174.18.234.0            [170/2560002816] via 174.18.123.3, 00:35:22, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:35:22, FastEthernet0/0 D EX    174.18.0.0 [170/30720] via 174.18.123.3, 00:00:37, FastEthernet0/0 D EX 192.10.18.0/24            [170/2560002816] via 174.18.123.3, 00:20:33, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:20:33, FastEthernet0/0      150.18.0.0/24 is subnetted, 6 subnets D EX    150.18.4.0            [170/2560002816] via 174.18.123.3, 00:20:33, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:20:33, FastEthernet0/0 D EX    150.18.5.0 [170/158720] via 174.18.123.3, 00:00:38, FastEthernet0/0 D EX    150.18.6.0 [170/158720] via 174.18.123.3, 00:00:38, FastEthernet0/0 D EX    150.18.2.0            [170/2560002816] via 174.18.123.3, 00:20:25, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:20:25, FastEthernet0/0 D EX    150.18.3.0            [170/2560002816] via 174.18.123.3, 00:20:37, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:20:37, FastEthernet0/0 D EX 205.90.31.0/24            [170/2560002816] via 174.18.123.3, 00:20:09, FastEthernet0/0            [170/2560002816] via 174.18.123.2, 00:20:09, FastEthernet0/0 

R6 also learns EIGRP 123 routes via R3:

Rack18R6#show ip route eigrp D EX 222.22.2.0/24 [170/2560002816] via 174.18.0.3, 00:23:59, FastEthernet0/0 D EX 220.20.3.0/24 [170/2560002816] via 174.18.0.3, 00:23:59, FastEthernet0/0      174.18.0.0/24 is subnetted, 3 subnets D EX    174.18.234.0            [170/2560002816] via 174.18.0.3, 01:00:18, FastEthernet0/0 D EX    174.18.123.0 [170/30720] via 174.18.0.3, 00:04:15, FastEthernet0/0 D EX 192.10.18.0/24 [170/2560002816] via 174.18.0.3, 00:27:22, FastEthernet0/0      150.18.0.0/24 is subnetted, 6 subnets D EX    150.18.4.0 [170/2560002816] via 174.18.0.3, 00:27:22, FastEthernet0/0 D       150.18.5.0 [90/156160] via 174.18.0.5, 01:31:17, FastEthernet0/0 D EX    150.18.1.0 [170/158720] via 174.18.0.3, 00:04:15, FastEthernet0/0 D EX    150.18.2.0 [170/2560002816] via 174.18.0.3, 00:24:18, FastEthernet0/0 D EX    150.18.3.0 [170/2560002816] via 174.18.0.3, 01:00:18, FastEthernet0/0 D EX 205.90.31.0/24 [170/2560002816] via 174.18.0.3, 00:23:59, FastEthernet0/0 

R3 will not transit OSPF backbone, due to our choice of administrative distances:

Rack18R3#show ip route | beg Gate Gateway of last resort is not set  O E2 222.22.2.0/24 [160/20] via 174.18.234.4, 02:22:45, Serial1/0 O E2 220.20.3.0/24 [160/20] via 174.18.234.4, 02:22:45, Serial1/0      174.18.0.0/24 is subnetted, 3 subnets C       174.18.234.0 is directly connected, Serial1/0 C       174.18.0.0 is directly connected, FastEthernet0/1 C       174.18.123.0 is directly connected, FastEthernet0/0 O E2 192.10.18.0/24 [160/20] via 174.18.234.4, 02:23:04, Serial1/0      150.18.0.0/24 is subnetted, 6 subnets O       150.18.4.0 [80/782] via 174.18.234.4, 02:23:04, Serial1/0 D       150.18.5.0 [90/156160] via 174.18.0.5, 02:59:03, FastEthernet0/1 D       150.18.6.0 [90/156160] via 174.18.0.6, 02:59:04, FastEthernet0/1 D EX    150.18.1.0 [170/156160] via 174.18.123.1, 02:25:48, FastEthernet0/0 O       150.18.2.0 [80/782] via 174.18.234.2, 02:23:04, Serial1/0 C       150.18.3.0 is directly connected, Loopback0 O E2 205.90.31.0/24 [160/20] via 174.18.234.4, 02:22:45, Serial1/0 

So we come up with (mostly) optimal redistribution configuration for our topology. What we learned so far, is that Split-horizon rule may also be implemented using the Administrative Disatnces. EIGRP implements this extremely useful feature automatically, while OSPF should be manually tuned for that. However, as we will learn in further examples, some additional work is needed for RIP. Also, now we remember that redistribution is non-transitive on local router. Finally, we learned a way to introduce a kind of hierarchy of administrative distances for a star-like routing domain topology (core transit domain, and stub edge domains). More complicated examples are to follow this post.

Understanding Redistribution (Part I)

Abstract: Describe the purpose of redistribution and the issues involved.
Prerequisites: Good understanding of IGP routing protocols (OSPF, EIGRP, RIPv2).

Let’s start straight with a rolling out a group of definitions. Redistribution is a process of passing the routing information from one routing domain to another. The ultimate goal of redistribution is to provide full IP connectivity between different routing domains. Another goal (not always required, though) is to provide redundant connectivity, i.e. backup paths between routing domains. Routing domain is a set of routers running the same routing protocol. Redistribution process is performed by border routers - i.e. routers belonging to more than one routing domain. On the contrary, internal routers belong just to one routing domain. Redistribution may be one-way (from one domain to another but not vice-versa) or two-way (bi-directional). Next, internal routes are the IGP prefixes native to a routing protocol; i.e. they are originated by IGP’s natural method, and their respective subnets belong to the IGP routing domain. External routes are the IGP prefixes injected into IGP routing domain via a border router - they have no corresponding IP subnets in the routing domain. They appear to be “attached” somehow to the border router that has originated them, and detailed information about their reachability is “compressed” and lost during the redistribution. Transit routing domain is the domain used as path to transport packets between two other routing domains. Domain becomes transit when two border routers perform bi-directional redistribution with two other routing domains. Stub routing domain is configured not to transit packets (effectively by blocking transit redistribution) between two other domains.

Let’s look at a picture to clarify the concepts.

Fig 1.1

The routing domains on the picture are described in the following table:

Table 1.1

Domain	Routers
OSPF	R2,R3,R4
EIGRP 123	R1,R2,R3
RIPv2	R4,R5,BB2
EIGRP 356	R3,R5,R6

Examples of internal routers are R1, R6, BB2. The border routers on the picture are reflected in the following table:

Table 1.2

Protocol	OSPF	EIGRP 356	EIGRP 123	RIPv2
OSPF	N/A	R3	R2,R3	R4
EIGRP 356	R3	N/A	R3	R5
EIGRP 123	R2,R3	R3	N/A	NONE
RIPv2	R4	R5	NONE	N/A

We will further use the figure and the tables for reference. Note that each domain on Fig 1.1 may be configured to be either transit or stub. For example, if we configure bi-directional redistribution on R3 between RIPv2 and OSPF and also on R2 between EIGRP 123 and OSPF, the OSPF domain will become transit point between two other domains. However, if we take R2 and R3, and configure R2 and R3 to send default routes into EIGRP 123, while redistributing EIGRP 123 into OSPF, we will make EIGRP 123 a stub domain.

What is redistribution needed for?

As we mentioned, the goal is to provide full connectivity between different routing domains. Usually, redistribution is needed when you merge two networks or migrate your network from one routing protocol to another. As such, redistribution is usually deemed to be a temporary solution. However, in reality, we often find that there is nothing more permanent than a temporary solution. And with the respect to CCIE lab exam, you are simply forced to face the redistribution, since the lab scenarios almost anytime involve a number of IGPs running on the topology. Note a very important “functional” property of redistribution: effectively, redistribution is used to “broadcast” the complete routing information among all the routing domain in a given topology.

What are the problems with redistribution?

a) Suboptimal routing

As it has been mentioned already, the external routes have no detailed information about their reachability. Even more, their original routing metric (e.g. cost) has to be converted to the native metric (e.g. to hop count). This is where a concept of seed metric appears. Seed metric is the initial metric assigned to external routes, redistributed into internal protocol (e.g. under RIP routing process: redistribute ospf 1 metric 1). In effect, external prefixes appear to be “attached” to the advertising border router, with “native” seed metric assigned. Due to such “simplifications”, and loss of detailed information, suboptimal routing may occur.

Example:

For our example, take EIGRP 123 routing domain. If RIPv2 routes enter EIGRP 123 domain by transiting OSPF and EIGRP 356 domains, packets from R1 to BB2 may take path R1->R2->R4->BB2 (if R2 sets better seed metric). In some worse cases, this route may even take path R1->R2->R3->R5->BB2 (if R2 thinks RIPv2 external routes transiting EIGRP 356 and redistributed into OSPF are better than RIPv2 injected into OSPF by R4) . Sometimes, due to asymmetric redistributions packets may take one path in forward direction and the other in the backward (e.g. packets from R1 to BB2 flow R1->R2->R4->BB2 and packets from BB2 to R1 flow BB2->R5->R3->R1).

b) Routing Loops

The other, more dangerous problem, is possibility that routing loops they may appear due to redistribution. Every routing protocol is able to converge to a loop-free routing only if it has full information on the existing topology. OSPF needs a complete link-state view of the intra-area topologies and star-like connectivity of non-backbone area to Area0. EIGRP requires a to carry out diffusing computations on all the routers in order to provide a loop free routing. RIP slow converges by executing a Bellman-Ford algorithm (gradient-driven optimization) on a whole topology. Since redistribution squashes and hides the original information, no IGP could guarantee a loop-free topology. Loops usually occur when IGP native information (internal routes) re-enter the routing domain as external prefixes due to use of two-way redistribution. The last important thing to note: external routes are always redistributed in a “distance-vector” fashion - i.e. advertised as a vector of prefixes and associated distances, even with link-state protocols.

Example:

Imagine that R4, R5 and R3 are configured for bi-directional redistribution between OSPF, RIPv2 and EIGRP 356 respectively. In effect, RIPv2 routes may transit EIGRP and OSPF, and appear on R4 as OSPF routes. Due to OSPF higher AD, they will be preferred at R4 over native routes, and will leak into RIPv2 domain. Further, BB2 may prefer those “looped back” routes (if say R4 is closer to BB2 than R5) and try to reach R5 connected interfaces via R4->R3. But thanks to two-way redistribution R3 will think R5 is better being reached via R4 - a loop is formed.

Is there a way to overcome those issues?

The answer is - “yes, by using a carefully designed redistribution policy”. Since routing protocols could not find and isolate the inter-domain loops, we either need to invent a new “super-routing” protocol, running on top of all IGPs (they call it BGP actually, and use to redistribute routing information between autonomous systems), or configure redistribution so that no routing loops would potentially occur and (hopefully) routing become “somewhat” optimal. We are going to describe a set of heuristics (rules of thumb) that could help us designing loop-less redistribution schemes. We start with the concept of administrative distance.

Administrative distance is a special preference value that allows selection of one protocols prefixes over another. This feature definitely needed on border routers (running multiple IGPs), which may receive the same prefixes via different IGPs. Cisco has assigned some default AD values to it’s IGPs (EIGRP, OSPF, RIPv2: 90, 110, 120), but we’ll see how this should be changed in accordance with policy. For now, we should note that two protocols - OSPF and EIGRP - offer capability to assign different administrative distance values to internal and external prefixes, thanks to their property to distinguish internal and external routes. This is a very powerful feature, which we are going to use extensively during our redistribution policy design.

Here comes our first rule of thumb. Rule 1: Router should always prefer internal prefix information over any external information. Clearly this is because external information is condensed and incomplete. For our example, if R4 receives a native prefix via RIPv2 and the same prefix via OSPF, it should prefer RIPv2 information over OSPF, even though OSPF has better AD than RIPv2 by default. This is easy to implement, thanks to the fact that we can change OSPF external AD independently of OSPF internal AD. The same rule holds true for any internal router: (not just for border routers) always prefer internal information over external for the same prefix. For example if R2 Loopback0 is advertised as native into EIGRP 123 and OSPF, and then redistributed into OSPF via R3 somehow, R4 should be configure so that OSPF external AD is higher than internal AD, and so that internal prefix is always preferred. This rule also eliminates suboptimal routing, by making sure no “dubious” paths are selected to reach a prefix. Effectively it is implemented so that all protocol external ADs are greater than any protocol internal AD (e.g. OSPF External AD > RIP Internal AD, EIGRP External AD > RIP Internal AD etc). However, RIPv2 has no notion of external routes.

So how could we implement this rule with RIPv2? First we should ensure that RIP AD is always greater than any other protocols external AD - on border routers, where this is needed. Next we need to configure so that RIPv2 internal routes have AD less that any other protocols external AD. To do this, we can take an access-list, enumerate all RIPv2 prefixes, and selectively assign a lower AD to those prefixes. Again, note that this procedure is needed on border routers only, and that you can re-use the access-list. Next, we need to make sure that inside a RIPv2 domain external routes are always considered worse than internal. We can effectively implement this by assigning a relatively high seed metric to redistributed (external) routes - say 8 hops. Since RIP topologies of large diameter are rare, it’s safe to assume with our policy that any prefix with metric (hop count) > 8 is an external one. (We may even use this property to distinguish RIPv2 internal prefixes in route-maps, thank to match metricfeature).

Next rule of thumb is known as Rule 2: Split-Horizon - Never redistribute a prefix injected from domain A into B back to domain A. This rule is targeted to eliminate “short” loops, by preventing the routing information leaked out of a routing domain to re-enter the same domain via some other point. For out example, it R2 and R3 are doing a two-way redistribution, we may want to prohibit EIGRP routes to transit the OSPF domain and enter the EIGRP domain again. This kind of situations occurs when two routing domains have more than one point of mutual redistribution. While the rule could be implemented playing with AD values or matching only internal routs in route-maps, it’s easier and more generic to use tagged routes and filter based on tag information. For example we may tag EIGRP 123 routes injected into OSPF with the tag value of “123″ and then configure to block routes with this tag, when redistributing from OSPF into EIGRP 123. Additionally, we tag OSPF routes with tag 110 when sending them to EIGRP 123 domain, and block routes with the same tag entering back the OSPF domain. While this rule may seem to be effective on detecting only “short” loops, it could be used to develop a simple, yet loop-free redistribution strategy.

First, recall how OSPF behaves with respect to inter-area routes exchange. In essence, all areas are linked to a backbone and form a star - loop-free - topology. OSPF then safely passes down the areas summary LSA using the distance-vector behavior, and never advertises those LSA back into backbone. This way, the core knows all the routing information and redistributes it down to leaves. And thanks to a loop-free “skeleton” we are guaranteed to never face any routing loops even with distance-vector advertisements. Now we can reuse this idea among the heterogenous routing domains. Take one routing domain and make it the center of the new star - in essence, make it the only transit domain in the topology. The other domains will effectively become “stub” domains, using our previous definitions - i.e. they exchange routes only with the core routing domain. Proceed with configuring two-way redistribution on border routers (enable route prefix exchange). If a given domain has more than one point of attachment to the star core (the backbone), configure to implement Rule 2 on border routers. Next, implement Rule 1 on border routers, to avoid suboptimal routing issues. That does the trick! For our example, we may configure mutual redistribution on R2 (EIGRP 123 and OSPF), R3 (EIGRP 123 and OSPF), R4 (RIPv2 and OSPF). We will then need to implement tag-based filtering on R2 and R3, as well as tune ADs in accordance with Rule 1. The detailed configuration examples will follow in the further publications.

Okay, now what if we don’t have a “central” routing domain attached to all other domains in topology? Let’s say R3 is not running OSPF in our example, and we have all routing domains connected in “ring” fashion. In short, the same idea still may be utilized, by replacing pure “star-like” topology with “tree”. Tree is loop-less too, so there is a guarantee that no loops will form. We are going to discuss this, and other more complicated scenarios in the next publications.

Python Study -- Get Environment

os.getenv(key, default=value)

Get the "key" environment variable, if it is not defined, use the default value as the result.

#!/usr/bin/env python
import osimport sys
VT_ROOT = os.getenv("VDE_TOOL_DIR", default = "/opt/vde/services/instances/vt2124")VT_CMD = VT_ROOT + "/bin/vde_tool"CT_CMD = VT_CMD + " ct "
print CT_CMDos.system

Word 使用技巧收集分享

Word是我们平常用的最多的Office软件之一，也是很多朋友平时工作时用得最多的工具了。今天我们收集了一些不错的Word技巧，希望能帮助大家提供一下工作的效率和方便性吧……

把文字替换成图片

首 先把图片复制到 剪贴板中，然后打开替换对话框，在“查找内容”框中输入将被替换的文字，接着在“替换为”框中输入“^c”（注意：输入的一定要是半角字符，c要小写）， 单击替换 即可。说明:“^c”的意思就是指令WordXP以剪贴板中的内容替换“查找内容”框中的内 容。按此原理，“^c”还可替换包括回车符在内的任何可以复制到剪贴板的可视内容，甚至Excel表格。

三招去掉页眉那条横线

1、在页眉中，在“格式”－“边框和底纹”中设置表格和边框为“无”，应用于“段落”
2、同上，只是把边框的颜色设置为白色（其实并没有删的，只是看起来没有了）
3、在“样式”栏里把“页眉”换成“正文”就行了——强烈推荐！
会多出--(两个横杠) 这是用户不愿看到的,又要多出一步作删除--
解决方法：替换时在前引号前加上一个空格 问题就解决了

插入日期和时间的快捷键

Alt+Shift+D：当前日期
Alt+Shift+T：当前时间

批量转换全角字符为半角字符

首先全选。然后“格式”→“更改大小写”，在对话框中先选中“半角”，确定即可

Word启动参数简介

单击“开始→运行”命令，然后输入Word所在路径及参数确定即可运行，如“C:\ PROGRAM FILES \MICROSOFT Office \Office 10\ WINWord.EXE /n”，这些常用的参数及功能如下：
/n：启动Word后不创建新的文件。
/a：禁止插件和通用模板自动启动。
/m：禁止自动执行的宏。
/w：启动一个新Word进程，独立与正在运行的Word进程。
/c：启动Word，然后调用Netmeeting。
/q：不显示启动画面。
另外对于常需用到的参数，我们可以在Word的快捷图标上单击鼠标右键，然后在“目标”项的路径后加上该参数即可。

快速打开最后编辑的文档

如果你希望Word在启动时能自动打开你上次编辑的文档，可以用简单的宏命令来完成：
(1)选择“工具”菜单中的“宏”菜单项，单击“录制新宏”命令打开“录制宏”对话框；
(2)在“录制宏”对话框中，在“宏名”输入框中输入“autoexec”，点击“确定”；
(3)从菜单中选择“文件”，点击最近打开文件列表中显示的第一个文件名；并“停止录制”。保存退出。下次再启动Word时，它会自动加载你工作的最后一个文档。

格式刷的使用

1、设定好文本1的格式。
2、将光标放在文本1处。
3、单击格式刷按钮。
4、选定其它文字(文本2)，则文本2的格式与文本1 一样。
若在第3步中单击改为双击，则格式刷可无限次使用，直到再次单击格式刷(或按Esc键)为止。

删除网上下载资料的换行符（象这种“↓”）

在查找框内输入半角^l(是英文状态下的小写L不是数字1),在替换框内不输任何内容，单击全部替换，就把大量换行符删掉啦。
选择性删除文件菜单下的最近使用的文件快捷方式。
工具→选项→常规把“列出最近使用文件数改为0”可以全部删除，若要选择性删除，可以按ctrl+Alt+ -三个键，光标变为一个粗减号后，单击文件，再单击要删除的快捷方式就行了。

建立一个矩形选区

一般的选区建立可用鼠标左键，或用shift键配合pgup、pgdn、home、end、箭头等功能键，当复制一个规则的矩形区域时，可先按住Alt键，然后用鼠标左键来选。我一般用此来删除段首多余的成块的空格。

将字体快速改为上标或下标的方法

本人在一次无意间发现了这个方法，选定你要下标的字，然后在英文状态下按住Ctrl，再按一下BASKSPACE旁的+/=的键，就可以了。上标只要在按Ctrl的同时也按住Shift,大家可以试试。

让Word表格快速一分为二

将光标定位在分开的表格某个位置上，按下“Ctrl+Shift+Enter”组合键。这时你就会发现表格中间自动插入一个空行，这样就达到了将一个表格一分为二的目的。

用Word来拆字

首 先点击“工具/自定义/命令/分解图片”，按住鼠标左键把它拖放到工具栏任意位置即可；然后点击“插入/图片/艺术字”，例如输入空心字“心”，选择该“ 心”字剪切，在选择性粘贴中选图片（Windows图元文件），选中该字，点击工具栏中的“分解图片”按钮，这样可以选择“心”中的任意笔画进行一笔一画 的拆分了。

快速删除段前段后的任意多个空格

选定这些段段落，单击居中按钮，然后再单击原来的那种对齐方式按钮（如果原来是居中对齐的，先单击其它对齐方式按钮，再单击居中按钮就行了），是不是这些空格全不见了？

只要打开WORD新建一个空文档的时候，出现的不是空的文档，而是我以前打的一份文档

首先:将资源管理器设置为显示所有文件和文件夹；
然后:
C:\Documents and Settings\Administrator\Application Data\Microsoft\Templates文件夹下将所有Normal.doc文件删掉；
然后：OK（XP系统）

快速输入平方的方法

先输入2,然后选重后,按ctrl加shift加+就可以了.

WORD中表格的选择性录入

1.设置好表格,选定表格-视图-工具-窗体-插入下拉型窗体域
2.输入数据,完成
3.点击锁按钮,保护,输入完后再点击进行其它的输入.

标点符号的全角/半的转换用：Ctrl+.

数字字母的全角/半的转换用：Shift+空格

轻松了解工具栏按钮的作用

按下“shift+F1”键，鼠标指针旁多了一个“？”号，想知道哪个按钮的作用，就用鼠标单击哪个。

要经常在文档中插入自己公司的信息

公司名称、公司住址、联系电话、联系人姓名、QQ号码
可以先选定这些内容，再单击工具→自动更正→在替换框中输入标记名称(如“公司信息”)→添加→确定，以后凡是在文档中要用到这个信息的地方键入“公司信息”（不要引号）这几个字后就自动替换成：
公司名称、公司住址、联系电话、联系人姓名、QQ号码
说明：有些输入法不支持这个功能，键入标记名称后要按一下空格才行。

快速换页的方法

双击某页的右下脚，光标即可定位在那里，然后按回车直到换页。ctrl＋回车点插入按纽，分隔符，选中分页符，然后确认就OK了 ！！！

表格的简单调整宽度

鼠标放在表格的右边框上带鼠标变成可以调整大小的时候
双击
根据表格内的内容调节表格大小

代替金山词霸

点工具——语言——翻译，在右边出现的搜索框中输入要查的单词，回车就可以翻译了。可以选择英语翻成中文或中文翻成英语。
第一次使用可能要安装。

[Alt]键实现标尺的精确定位

如 果你经常使用水平标尺来精确定位标签、页边框、首字缩进及页面对象的位置，那么你点击标尺设置页边框或标签时，您只可以将其设置为1字符或2字符，但不能 设为1.5字符！要想设置更为精确的度量单位（例如百分之几字符），在按住[Alt]键的同时，点击并移动标尺或边框，此时标尺将用数字精确显示出当前的 位置为百分之几字符位置。

用“记事本”去除格式

网 页上COPY下来的东西往往都是有网格的，如果直接粘贴在WORD中会杂乱无章。先粘贴到记事本当中，再粘贴到WORD中，就可以去除网格等格式，再全选 选择清除格式，居中再取消居中即可取消所有格式。可以直接在WORD中进行：（菜单）编辑/选择性粘贴……/无格式文本/确定。这样省事多了。

快速将文档转换成图片

先把欲想转换的文档保存退出.如:保存在桌面
然后新建一个文件.把想转换的文档(鼠标左建按住该文档不放)直接施放在页面上

恢复office的默认设置

比如不小心把word设置乱了(如删了菜单栏等等).
查找normal.dot直接删除.
下一次启动word会恢复默认值.

让Word只粘贴网页中的文字而自动去除图形和版式

方法一、选中需要的网页内容并按“Ctrl+C”键复制，打开Word，选择菜单“编辑”→“选择性粘贴”，在出现的对话框中选择“无格式文本”。
方法二、选中需要的网页内容并按“Ctrl+C” 键复制，打开记事本等纯文本编辑工具，按“Ctrl+V”键将内容粘贴到这些文本编辑器中，然后再复制并粘贴到Word中。

ctrl+alt+f可以输入脚注

这个对于经常写论文的朋友应该有点帮助。

将阿拉伯数字转换成中文数字或序号

1、先输入阿拉伯数字(如1234)，全选中，单击“插入/数字/数字类型（壹、贰……）/确定”，即变为大写数字（如壹仟贰佰叁拾肆），会计朋友非常适用。
2、其他像一千二百三十四，甲、乙……，子、丑……，罗马数字等的转换，可参考上法。

Word中的常用快捷键吧

“字体”对话框 Ctrl+D
选择框式工具栏中的“字体”框 Ctrl+Shift+F
加粗 Ctrl+B
倾斜 Ctrl+I
下划线Ctrl+U
“上标”效果 Ctrl+Shift+=
“下标”效果 Ctrl+=
“关闭”命令 Ctrl+W

Word快捷键一览表

序号 快捷键CTRL+ 代表意义
1…………Z…………撤消
2…………A…………全选
3…………X…………剪切
4…………C…………复制
5…………V…………粘贴
6…………S…………保存
7…………B…………加粗
8………… Q…………左对齐
9…………E…………居中
10…………R…………右对齐
11…………]…………放大
22…………[…………缩小
12…………N…………新建文档
13…………I…………字体倾斜
14…………W…………退出
15…………P…………打印
16…………U…………下划线
17…………O…………打开
18…………k…………插入超级连接
19…………F…………查找
20…………H…………替换
21…………G…………定位
23…Ctrl+Alt+L……带括号的编号
24…Ctrl+Alt+.________…
25…Alt+数字………区位码输入
26…Ctrl+Alt+Del………关机
27…Ctrl+Alt+Shift+?……¿
28…Ctrl+Alt+Shift+!……¡
29…Alt+Ctrl+E……………？
30…Alt+Ctrl+R……………®
31…Alt+Ctrl+T……………™
32…Alt+Ctrl+Ctrl…………©
33……Ctrl+D……………格式字体
34……Ctrl+Shift+= ………上标
35……Ctrl+=………………下标
36……Ctrl+Shift+>……放大字体
37……Ctrl+Shift+

Word双面打印技巧

　　 我们平时用电脑的时候可能都少不了打印材料，Word是我们平常用的最多的Office软件之一。有时我们要用Word打印许多页的文档，出于格式要求或为了节省纸张，会进行双面打印。
我们一般常用的操作方法是:选择“打印”对话框底部的“打印”下拉列表框中的“打印奇数页”或“打印偶数页”，来实现双面打印。我们设定为先打印奇数 页。等奇数页打印结束后，将原先已打印好的纸反过来重新放到打印机上，选择该设置的“打印偶数页”，单击“确定”按钮。这样通过两次打印命令就可以实现双 面打印。
我们也可以利用另一种更灵活的双面打印方式:打开“打印”对话框，选中“人工双面打印”，确定后就会出现一个“请将出纸器中已打印好 的一面的纸取出并将其放回到送纸器中，然后'确定’按键，继续打印”的对话框并开始打印奇数页，打完后将原先已打印好的纸反过来重新放到打印机上，然后按 下该对话框的“确定”按键，Word就会自动再打印偶数页，这样只用一次打印命令就可以了。
两种方法对比，后者较前者更为方便。

Configuring PPPoE

One of the topics covered by the CCNP Implementing Secure Converged WANs exam is Point-to-Point Protocol over Ethernet, more casually known as PPPoE. Unfortunately, the exam only covers the configuration of the client side; not very handy if you intend to lab out a functioning link (highly recommended). Here we'll cover the configuration of sides across an Ethernet link to demonstrate connection establishment.

PPPoE provides an emulated (and optionally authenticated) point-to-point link across a shared medium, typically a broadband aggregation network such as those found in DSL service providers. In fact, a very common scenario is to run a PPPoE client on the customer side (commonly on a SOHO Linksys or similar brand router), which connects to and obtains its configuration from the PPPoE server (head-end router) at the ISP side. Note that ATM is typically run between the customer's modem and the DSLAM, though it will be transparent in this lab since our PPPoE client exists on a separate device.

Server Configuration

The first task at the ISP end is to configure a Broadband Aggregation (BBA) group which will handle incoming PPPoE connection attempts. We'll name this MyGroup, and bind it to a virtual template to be created shortly.

ISP(config)# bba-group pppoe MyGroup ISP(config-bba-group)# virtual-template 1 

Here we can also apply PPPoE session limits. For example, we can limit the number of sessions established per client MAC address (setting this limit to 2 allows a new session to be established immediately if the prior session was orphaned and is waiting to expire). This is an optional step.

ISP(config-bba-group)# sessions per-mac limit 2 

Next we'll create the virtual template for the customer-facing interface. When a PPPoE client initiates a session with this router, the router automatically spawns a virtual interface to represent that point-to-point connection.

ISP(config)# interface virtual-template 1 

At a minimum, we'll need to configure two items on our virtual template: an IP address, and a pool of IP addresses from which clients are assigned a negotiated address (similar in operation to DHCP).

ISP(config-if)# ip address 10.0.0.1 255.255.255.0 ISP(config-if)# peer default ip address pool MyPool 

You may be wondering where the IP pool is defined. Well, it isn't; that's what we have to do next. Back in global configuration mode, we define a local IP pool named MyPool with the starting and ending addresses of an IP range. If you've configured DHCP on IOS before, you should find this task very familiar.

ISP(config)# ip local pool MyPool 10.0.0.2 10.0.0.254 

Last, we need to enable our PPPoE group on the interface facing the customer network.

ISP(config)# interface f0/0 ISP(config-if)# no ip address ISP(config-if)# pppoe enable group MyGroup ISP(config-if)# no shutdown 

Note that this interface should not have an IP address; the addressing is provided by our virtual template.

Client Configuration

Client configuration is relatively simple. We create a dialer interface to handle the PPPoE connection, and tie it to a physical interface which provides the transport.

Creating our PPPoE dialer interface:

CPE(config)# interface dialer1 CPE(config-if)# dialer pool 1 CPE(config-if)# encapsulation ppp CPE(config-if)# ip address negotiated 

The line ip address negotiated instructs the client to use an IP address provided by the PPPoE server.

The PPP header adds 8 bytes of overhead to each frame. Assuming the default Ethernet MTU of 1500 bytes, we'll want to lower our MTU on the dialer interface to 1492 to avoid unnecessary fragmentation.

CPE(config-if)# mtu 1492 

Lastly we assign our ISP-facing interface to our newly created PPPoE dial group:

CPE(config)# interface f0/0 CPE(config-if)# no ip address CPE(config-if)# pppoe-client dial-pool-number 1 CPE(config-if)# no shutdown 

If all is well, you should see a notification indicating the PPPoE session has successfully formed:

%DIALER-6-BIND: Interface Vi1 bound to profile Di1 %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up 

We can verify that interface Dialer1 has negotiated an IP address from the ISP router:

CPE# show ip interface brief  Interface                  IP-Address      OK? Method Status                Protocol FastEthernet0/0            unassigned      YES manual up                    up       [...] Virtual-Access1            unassigned      YES unset  up                    up       Dialer1                    10.0.0.2        YES IPCP   up                    up 

show pppoe session shows our PPPoE session with the ISP router terminated on Dialer0, via FastEthernet0/0:

CPE# show pppoe session       1 client session   Uniq ID  PPPoE  RemMAC          Port                  Source   VA         State            SID  LocMAC                                         VA-st     N/A     16  ca00.4843.0008  Fa0/0                 Di1      Vi1        UP                       ca01.4843.0008                                 UP 

Authentication

Of course, at this point anyone can connect via PPPoE. Generally we only want to provide service to trusted (e.g. paying) customers, so adding some low-layer authentication would be a prudent step. PPP can use PAP or CHAP to authenticate clients, with the later heavily preferred.

On our ISP router, we'll create a local user account name CPE and the password MyPassword. (In real practice, account creation is typically performed on a back-end server and referenced via RADIUS or TACACS+ rather than being stored locally.)

ISP(config)# username CPE password MyPassword 

Next we enforce CHAP authentication on our virtual template:

ISP(config)# interface virtual-template 1 ISP(config-if)# ppp authentication chap callin 

This will terminate our client session, as we can see from the logs on CPE:

%DIALER-6-UNBIND: Interface Vi1 unbound from profile Di1 %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down 

To reestablish the connection from CPE, we'll need to enter the proper credentials:

CPE(config)# interface dialer 1 CPE(config-if)# ppp chap password MyPassword 

We should see the PPPoE session come back up a few seconds later after successfully authenticating. debug ppp authentication can be used on the ISP router to monitor the CHAP exchange:

ppp50 PPP: Using vpn set call direction ppp50 PPP: Treating connection as a callin ppp50 PPP: Session handle[E800003A] Session id[50] ppp50 PPP: Authorization required ppp50 CHAP: O CHALLENGE id 1 len 24 from "ISP" ppp50 CHAP: I RESPONSE id 1 len 24 from "CPE" ppp50 PPP: Sent CHAP LOGIN Request ppp50 PPP: Received LOGIN Response PASS Vi1.1 PPP: Sent LCP AUTHOR Request Vi1.1 PPP: Sent IPCP AUTHOR Request Vi1.1 LCP: Received AAA AUTHOR Response PASS Vi1.1 IPCP: Received AAA AUTHOR Response PASS Vi1.1 CHAP: O SUCCESS id 1 len 4 

The final configuration of both routers are attached below.

File Attachments

• pppoe_configs.txt (641 bytes)