I will call this NTP blog NTP Scenario 2: NTP with access-group filtering.
R4, R5, and R6 are connected via full mesh frame-relay
R6 will be the NTP server.
In scenario 1 we set up R4 to sync to R6. In this scenario we
will prevent R5 from syncing with R6 by using ntp access-group command.
I have never used this command before, so I hope I am understanding it correctly. If not, please let me know how else to test this command.
On R6 we have the following ACL:
access-list 1 permit 172.12.45.4
access-list 1 permit 127.127.7.1
172.12.45.4 is the address of R4. 127.127.7.1 is the IP address that a cisco router uses as it's reference when you make the router an NTP master. This must be added to the ACL or it will become unsynchronized with itself.
In global config mode we enter:
ntp access-group serve-only 1
Let's check the current times:
R5#show clock
16:15:04.031 UTC Sat May 31 2008
R6#show clock
16:31:45.687 UTC Sat May 31 2008
R5 is about 15 minutes behind. I don't know a way to debug on R6 to make sure it's working, so what I will do is wait about 10 minutes then add R5's IP address to ACL. I think 10 minutes is sufficient to prove that R6 is not allowing R5 to sync to it.
...
...
Well it's almost 20 minutes now. Let's check if R4 is synchronized:
R4#show ntp status | inc Cloc
Clock is synchronized, stratum 3, reference is 172.12.45.6
How about R5:
R5#sho ntp status | inc Clock
Clock is unsynchronized, stratum 16, no reference clock
Some quick show clocks:
R4#show clock
16:49:06.505 UTC Sat May 31 2008
R5#show clock
16:32:29.755 UTC Sat May 31 2008
R6#show clock
16:49:12.335 UTC Sat May 31 2008
R5 is still unsynchronized and more than 15 minutes behind R6. Let's add R5's address to ACL 1 on R6 and see how long it takes to sync...
R6(config)#access-list 1 permit 172.12.45.5
We'll debug on R5:
R5#debug ntp sync
NTP clock synchronization debugging is on
R5#sho ntp status | inc Clock
Clock is unsynchronized, stratum 16, no reference clock
R5#
May 31 16:33:54.039: NTP: synced to new peer 172.12.45.6
Took less than a minute!
This is the second of many NTP scenarios to come. It really seems so simple, but I have always had problems understanding NTP server/peer relationships and authentication configurations. So these will be the topics of future NTP blogs. Hopefully I (and you!) will become NTP masters in time for CCIE :)
Saturday, May 31, 2008
Basic NTP Configuration
I will call this NTP Scenario 1: Basic NTP with no authentication. There will be more blogs about NTP but this is just to get it started.
R4, R5, and R6 are connected via full mesh frame-relay
R6 will be the NTP server.
First set the clock on R6:
R6#clock set 15:47:30 31 May 2008
*May 31 15:47:30.003: %SYS-6-CLOCKUPDATE: System clock has been updated from 01:
05:19 UTC Fri Mar 1 2002 to 15:47:30 UTC Sat May 31 2008, configured from consol
e by console.
Verify the time with show clock:
R6#show clock
15:47:36.651 UTC Sat May 31 2008
Configure R6 as the master along with stratum:
R6#conf t
R6(config)#ntp master ?
<1-15> Stratum number
R6(config)#ntp master 3
R6(config)#^Z
Verify that R6 is synced with itself:
R6#show ntp associations
address ref clock st when poll reach delay offset disp
*~127.127.7.1 127.127.7.1 2 22 64 1 0.0 0.00 15875.
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
R6#show ntp status
Clock is synchronized, stratum 3, reference is 127.127.7.1
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24
reference time is CBEBF22C.1583DCD8 (15:50:04.084 UTC Sat May 31 2008)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 15875.02 msec, peer dispersion is 15875.02 msec
Now it's time to configure the clients, let's first check the time on R4:
R4#show clock
*03:03:44.823 UTC Fri Mar 1 2002
R4#conf t
R4(config)#ntp server 172.12.45.6
R4(config)#^Z
R4#show clock
*03:04:52.047 UTC Fri Mar 1 2002
R4#
Notice the time is 6 years behind the current date, I have noticed that NTP will not sync when the times are so far apart (Not sure how this works, but let's manually 'push' R4 a little closer)
R4#clock set 15:30:40 31 May 2008
Now we're about 15 minutes behind. Let's do some debugging:
R4#debug ntp sync
NTP clock synchronization debugging is on
.May 31 15:31:43.107: NTP: synced to new peer 172.12.45.6
Noe that we're synced let's verify on R6 and R4:
R4#show clock
15:59:42.466 UTC Sat May 31 2008
R6#show clock
15:59:41.135 UTC Sat May 31 2008
Looks good. I will use this topology for other NTP labs so stay tuned...
R4, R5, and R6 are connected via full mesh frame-relay
R6 will be the NTP server.
First set the clock on R6:
R6#clock set 15:47:30 31 May 2008
*May 31 15:47:30.003: %SYS-6-CLOCKUPDATE: System clock has been updated from 01:
05:19 UTC Fri Mar 1 2002 to 15:47:30 UTC Sat May 31 2008, configured from consol
e by console.
Verify the time with show clock:
R6#show clock
15:47:36.651 UTC Sat May 31 2008
Configure R6 as the master along with stratum:
R6#conf t
R6(config)#ntp master ?
<1-15> Stratum number
R6(config)#ntp master 3
R6(config)#^Z
Verify that R6 is synced with itself:
R6#show ntp associations
address ref clock st when poll reach delay offset disp
*~127.127.7.1 127.127.7.1 2 22 64 1 0.0 0.00 15875.
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
R6#show ntp status
Clock is synchronized, stratum 3, reference is 127.127.7.1
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24
reference time is CBEBF22C.1583DCD8 (15:50:04.084 UTC Sat May 31 2008)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 15875.02 msec, peer dispersion is 15875.02 msec
Now it's time to configure the clients, let's first check the time on R4:
R4#show clock
*03:03:44.823 UTC Fri Mar 1 2002
R4#conf t
R4(config)#ntp server 172.12.45.6
R4(config)#^Z
R4#show clock
*03:04:52.047 UTC Fri Mar 1 2002
R4#
Notice the time is 6 years behind the current date, I have noticed that NTP will not sync when the times are so far apart (Not sure how this works, but let's manually 'push' R4 a little closer)
R4#clock set 15:30:40 31 May 2008
Now we're about 15 minutes behind. Let's do some debugging:
R4#debug ntp sync
NTP clock synchronization debugging is on
.May 31 15:31:43.107: NTP: synced to new peer 172.12.45.6
Noe that we're synced let's verify on R6 and R4:
R4#show clock
15:59:42.466 UTC Sat May 31 2008
R6#show clock
15:59:41.135 UTC Sat May 31 2008
Looks good. I will use this topology for other NTP labs so stay tuned...
Labels:
network management,
ntp
IP Accounting for traffic violations
R6 <---FRAME---> R5 <----ETHERNET---> R3
First step is to create the ACL that blocks traffic. Here will block traffic (and configure accounting) for packets from R6 to R3. IP address 6.6.6.10 is a loopback on R6 being advertised into OSPF to R5 and on to R3. 3.3.3.3 is the loopback on R3.
R5#show run | section access-list 101
access-list 101 deny ip host 6.6.6.10 host 3.3.3.3
access-list 101 permit ip any any
Apply the ACL to the interface where traffic is to be restricted. FastEthernet0/0 is the interface connected to R3's LAN interface. Enable accounting for access-violations on that interface with the command "ip accounting access-violations"
R5#show run int f0/0
Building configuration...
Current configuration : 153 bytes
!
interface FastEthernet0/0
ip address 172.12.34.5 255.255.255.0
ip access-group 101 out
ip accounting access-violations
speed 100
full-duplex
end
Ping from R6 to verify that traffic is blocked:
R6#ping 3.3.3.3 source 6.6.6.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 6.6.6.10
U.U.U
Success rate is 0 percent (0/5)
Verify accounting on R5:
R5#show ip accounting access-violations
Source Destination Packets Bytes ACL
6.6.6.10 3.3.3.3 6 600 101
Accounting data age is 4
The output of the command shows how many packets (6) and bytes (600) were blocked as well as the ACL (101) that blocked them.
First step is to create the ACL that blocks traffic. Here will block traffic (and configure accounting) for packets from R6 to R3. IP address 6.6.6.10 is a loopback on R6 being advertised into OSPF to R5 and on to R3. 3.3.3.3 is the loopback on R3.
R5#show run | section access-list 101
access-list 101 deny ip host 6.6.6.10 host 3.3.3.3
access-list 101 permit ip any any
Apply the ACL to the interface where traffic is to be restricted. FastEthernet0/0 is the interface connected to R3's LAN interface. Enable accounting for access-violations on that interface with the command "ip accounting access-violations"
R5#show run int f0/0
Building configuration...
Current configuration : 153 bytes
!
interface FastEthernet0/0
ip address 172.12.34.5 255.255.255.0
ip access-group 101 out
ip accounting access-violations
speed 100
full-duplex
end
Ping from R6 to verify that traffic is blocked:
R6#ping 3.3.3.3 source 6.6.6.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 6.6.6.10
U.U.U
Success rate is 0 percent (0/5)
Verify accounting on R5:
R5#show ip accounting access-violations
Source Destination Packets Bytes ACL
6.6.6.10 3.3.3.3 6 600 101
Accounting data age is 4
The output of the command shows how many packets (6) and bytes (600) were blocked as well as the ACL (101) that blocked them.
Labels:
access-list,
accounting,
ios feature set,
security
Friday, May 30, 2008
BGP distance command's 3 arguments
In BGP configuration mode, the distance command has 3 arguments:
R6(config-router)#distance bgp ?
<1-255> Distance for routes external to the AS
R6(config-router)#distance bgp 13 ?
<1-255> Distance for routes internal to the AS
R6(config-router)#distance bgp 13 26 ?
<1-255> Distance for local routes
R6(config-router)#distance bgp 13 26
External BGP and Internal BGP routes are easy enough to understand, but what exactly is the third option "local routes" for and when do you see it?
Here is an example:
R1#show run
!
interface Loopback10
ip address 10.10.10.1 255.255.255.0
!
interface Loopback11
ip address 11.11.11.11 255.255.255.0
!
router bgp 65000
no synchronization
distance bgp 13 26 8
network 10.10.10.0 mask 255.255.255.0
aggregate-address 10.0.0.0 254.0.0.0
!
R1#show ip route
C 172.12.15.0 is directly connected, Serial1/1
C 172.12.123.0 is directly connected, Serial1/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, Loopback10
11.0.0.0/24 is subnetted, 1 subnets
C 11.11.11.0 is directly connected, Loopback11
B 10.0.0.0/7 [8/0] via 0.0.0.0, 00:02:02, Null0
The null route gets the "local route" distance when you configure aggregate routes.
Do you know any other scenarios?
R6(config-router)#distance bgp ?
<1-255> Distance for routes external to the AS
R6(config-router)#distance bgp 13 ?
<1-255> Distance for routes internal to the AS
R6(config-router)#distance bgp 13 26 ?
<1-255> Distance for local routes
R6(config-router)#distance bgp 13 26
External BGP and Internal BGP routes are easy enough to understand, but what exactly is the third option "local routes" for and when do you see it?
Here is an example:
R1#show run
!
interface Loopback10
ip address 10.10.10.1 255.255.255.0
!
interface Loopback11
ip address 11.11.11.11 255.255.255.0
!
router bgp 65000
no synchronization
distance bgp 13 26 8
network 10.10.10.0 mask 255.255.255.0
aggregate-address 10.0.0.0 254.0.0.0
!
R1#show ip route
C 172.12.15.0 is directly connected, Serial1/1
C 172.12.123.0 is directly connected, Serial1/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, Loopback10
11.0.0.0/24 is subnetted, 1 subnets
C 11.11.11.0 is directly connected, Loopback11
B 10.0.0.0/7 [8/0] via 0.0.0.0, 00:02:02, Null0
The null route gets the "local route" distance when you configure aggregate routes.
Do you know any other scenarios?
Labels:
administrative distance,
bgp
OSPF - cost of summary routes
R2 --[area1]-- R5 --[area0]-- R6
R2 is advertising 4 loopbacks into area 1, each with different costs:
R2#show run | section interface
interface Loopback0
ip address 2.2.2.2 255.255.255.255
interface Loopback1
ip address 2.2.2.3 255.255.255.255
ip ospf cost 100
interface Loopback2
ip address 2.2.2.4 255.255.255.255
ip ospf cost 200
interface Loopback3
ip address 2.2.2.5 255.255.255.255
ip ospf cost 300
R2#show run | section router ospf
router ospf 1
log-adjacency-changes
network 2.2.2.0 0.0.0.255 area 25
network 172.12.25.0 0.0.0.255 area 25
Router 6 has the following entries in the route table:
R6#show ip route | section 2.0.0.0
2.0.0.0/32 is subnetted, 4 subnets
O IA 2.2.2.2 [110/129] via 172.12.45.5, 01:17:58, Serial1/1
O IA 2.2.2.3 [110/228] via 172.12.45.5, 00:04:18, Serial1/1
O IA 2.2.2.4 [110/328] via 172.12.45.5, 00:04:35, Serial1/1
O IA 2.2.2.5 [110/428] via 172.12.45.5, 00:04:45, Serial1/1
R6#
Now if I want to summarize these routes into 2.2.2.0/24, what would the cost of the summary route be?
On router 5:
R5(config)#router ospf 1
R5(config-router)#area 25 range 2.2.2.0 255.255.255.0
R5(config-router)#
On router 6:
R6#show ip route | section 2.0.0.0
2.0.0.0/24 is subnetted, 1 subnets
O IA 2.2.2.0 [110/129] via 172.12.45.5, 00:00:02, Serial1/1
The summary route takes the lowest cost of the specific routes, in this case the cost 129 of route to 2.2.2.2
Ah but wait!
This behavior was changed in RFC 2328. In RFC 2328, the cost of the summary route should be the cost of the component route with the highest metric. To change this behavior in IOS, enter the following command (on R5 in this example):
R5(config-router)#no compatible rfc1583
Now check R6:
R6#show ip route | section 2.0.0.0
2.0.0.0/24 is subnetted, 1 subnets
O IA 2.2.2.0 [110/428] via 172.12.45.5, 00:01:42, Serial1/1
The cost is 428 which was the cost of the route to 2.2.2.5.
R2 is advertising 4 loopbacks into area 1, each with different costs:
R2#show run | section interface
interface Loopback0
ip address 2.2.2.2 255.255.255.255
interface Loopback1
ip address 2.2.2.3 255.255.255.255
ip ospf cost 100
interface Loopback2
ip address 2.2.2.4 255.255.255.255
ip ospf cost 200
interface Loopback3
ip address 2.2.2.5 255.255.255.255
ip ospf cost 300
R2#show run | section router ospf
router ospf 1
log-adjacency-changes
network 2.2.2.0 0.0.0.255 area 25
network 172.12.25.0 0.0.0.255 area 25
Router 6 has the following entries in the route table:
R6#show ip route | section 2.0.0.0
2.0.0.0/32 is subnetted, 4 subnets
O IA 2.2.2.2 [110/129] via 172.12.45.5, 01:17:58, Serial1/1
O IA 2.2.2.3 [110/228] via 172.12.45.5, 00:04:18, Serial1/1
O IA 2.2.2.4 [110/328] via 172.12.45.5, 00:04:35, Serial1/1
O IA 2.2.2.5 [110/428] via 172.12.45.5, 00:04:45, Serial1/1
R6#
Now if I want to summarize these routes into 2.2.2.0/24, what would the cost of the summary route be?
On router 5:
R5(config)#router ospf 1
R5(config-router)#area 25 range 2.2.2.0 255.255.255.0
R5(config-router)#
On router 6:
R6#show ip route | section 2.0.0.0
2.0.0.0/24 is subnetted, 1 subnets
O IA 2.2.2.0 [110/129] via 172.12.45.5, 00:00:02, Serial1/1
The summary route takes the lowest cost of the specific routes, in this case the cost 129 of route to 2.2.2.2
Ah but wait!
This behavior was changed in RFC 2328. In RFC 2328, the cost of the summary route should be the cost of the component route with the highest metric. To change this behavior in IOS, enter the following command (on R5 in this example):
R5(config-router)#no compatible rfc1583
Now check R6:
R6#show ip route | section 2.0.0.0
2.0.0.0/24 is subnetted, 1 subnets
O IA 2.2.2.0 [110/428] via 172.12.45.5, 00:01:42, Serial1/1
The cost is 428 which was the cost of the route to 2.2.2.5.
Labels:
ospf,
route summarization
OSPF - point-to-multipoint with /32 routes for neighbors
For OSPF point-to-multipoint networks, host routes to the neighbors will exist in the route table
It is unusual, but as designed.
Notice the last two routes:
R6#show ip route | inc /32
2.0.0.0/32 is subnetted, 1 subnets
3.0.0.0/32 is subnetted, 1 subnets
4.0.0.0/32 is subnetted, 1 subnets
5.0.0.0/32 is subnetted, 1 subnets
6.0.0.0/32 is subnetted, 1 subnets
O 172.12.45.5/32 [110/64] via 172.12.45.5, 00:34:42, Serial1/1
O 172.12.45.4/32 [110/64] via 172.12.45.4, 00:34:42, Serial1/1
These are addresses of OSPF neighbors:
R6#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
4.4.4.4 0 FULL/ - 00:01:37 172.12.45.4 Serial1/1
5.5.5.5 0 FULL/ - 00:01:37 172.12.45.5 Serial1/1
R6#
The host route is described in the router LSA for the advertising router:
(see 3rd entry)
R6#show ip ospf database router 4.4.4.4
OSPF Router with ID (6.6.6.6) (Process ID 1)
Router Link States (Area 0)
Routing Bit Set on this LSA
LS age: 889
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 4.4.4.4
Advertising Router: 4.4.4.4
LS Seq Number: 80000004
Checksum: 0x7CEA
Length: 72
Area Border Router
Number of Links: 4
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 5.5.5.5
(Link Data) Router Interface address: 172.12.45.4
Number of TOS metrics: 0
TOS 0 Metrics: 64
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 6.6.6.6
(Link Data) Router Interface address: 172.12.45.4
Number of TOS metrics: 0
TOS 0 Metrics: 64
Link connected to: a Stub Network
(Link ID) Network/subnet number: 172.12.45.4
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 0
Link connected to: a Stub Network
(Link ID) Network/subnet number: 4.4.4.4
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 1
The link is a stub network, however stub networks (not to be confused with stub areas) are usually only for links without OSPF neighbors.
Why are these host routes necessary?
Not really sure right now, but it is per RFC 2328, section 12.4.1.4.
It is unusual, but as designed.
Notice the last two routes:
R6#show ip route | inc /32
2.0.0.0/32 is subnetted, 1 subnets
3.0.0.0/32 is subnetted, 1 subnets
4.0.0.0/32 is subnetted, 1 subnets
5.0.0.0/32 is subnetted, 1 subnets
6.0.0.0/32 is subnetted, 1 subnets
O 172.12.45.5/32 [110/64] via 172.12.45.5, 00:34:42, Serial1/1
O 172.12.45.4/32 [110/64] via 172.12.45.4, 00:34:42, Serial1/1
These are addresses of OSPF neighbors:
R6#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
4.4.4.4 0 FULL/ - 00:01:37 172.12.45.4 Serial1/1
5.5.5.5 0 FULL/ - 00:01:37 172.12.45.5 Serial1/1
R6#
The host route is described in the router LSA for the advertising router:
(see 3rd entry)
R6#show ip ospf database router 4.4.4.4
OSPF Router with ID (6.6.6.6) (Process ID 1)
Router Link States (Area 0)
Routing Bit Set on this LSA
LS age: 889
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 4.4.4.4
Advertising Router: 4.4.4.4
LS Seq Number: 80000004
Checksum: 0x7CEA
Length: 72
Area Border Router
Number of Links: 4
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 5.5.5.5
(Link Data) Router Interface address: 172.12.45.4
Number of TOS metrics: 0
TOS 0 Metrics: 64
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 6.6.6.6
(Link Data) Router Interface address: 172.12.45.4
Number of TOS metrics: 0
TOS 0 Metrics: 64
Link connected to: a Stub Network
(Link ID) Network/subnet number: 172.12.45.4
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 0
Link connected to: a Stub Network
(Link ID) Network/subnet number: 4.4.4.4
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 1
The link is a stub network, however stub networks (not to be confused with stub areas) are usually only for links without OSPF neighbors.
Why are these host routes necessary?
Not really sure right now, but it is per RFC 2328, section 12.4.1.4.
Labels:
ospf,
Point-to-multipoint,
route table
Troubleshooting OSPF over Frame-Relay Part 1
Scenario:
Full mesh of PVCs between 3 routers: R4 R5 and R6
Frame-relay map statements DO NOT have broadcast statement
Adjacencies do not form.
This is from debug ip packet on R6:
R6#debug ip packet
IP packet debugging is on
*Mar 1 01:00:26.367: IP: s=172.12.45.6 (local), d=224.0.0.5 (Serial1/1), len 76, sending broad/multicast
*Mar 1 01:00:26.371: IP: s=172.12.45.6 (local), d=224.0.0.5 (Serial1/1), len 76, encapsulation failed
After enabling broadcast on the frame maps, adjacencies came up
Solution:
Point-to-multipoint ospf networks need broadcast keyword on frame-relay map.
Without it you will see "encapsulation failed" when the router tries to send multicast hellos.
Full mesh of PVCs between 3 routers: R4 R5 and R6
Frame-relay map statements DO NOT have broadcast statement
Adjacencies do not form.
This is from debug ip packet on R6:
R6#debug ip packet
IP packet debugging is on
*Mar 1 01:00:26.367: IP: s=172.12.45.6 (local), d=224.0.0.5 (Serial1/1), len 76, sending broad/multicast
*Mar 1 01:00:26.371: IP: s=172.12.45.6 (local), d=224.0.0.5 (Serial1/1), len 76, encapsulation failed
After enabling broadcast on the frame maps, adjacencies came up
Solution:
Point-to-multipoint ospf networks need broadcast keyword on frame-relay map.
Without it you will see "encapsulation failed" when the router tries to send multicast hellos.
Labels:
debug,
frame-relay,
ospf,
Point-to-multipoint
My CCIE Lab v2?
I hoped to build my home lab around dynamips and real life 3550/3560 switches but I ran into some limitations with my PC's and dynamips. Since I have already forked over about $4,000 for 2 3550s and 3560s and I decided to fork over a little more for some routers. I found 3640 routers with max ram/flash and nm-2E2W for $199 OBO. I made an offer for 6 at $179 and the seller agreed. Total was $1199 with shipping, which puts my running total at about $5200. I still need to get a rack and brackets for the routers/switches, plus a terminal server made from a 2511 or something. I hope to have the lab completed fully for under $6000. This is probably the most expensive thing I have ever done but the having the real life lab is definitely a must in my scenario. It feels good to be on my way!
Introduction
This is my first post on my new blog. I created this blog in hopes to encourage and/or help others who wish to pursue CCIE or just gain knowledge about Cisco Routers and Switches. I will be detailing my CCIE pursuit in this blog including how I went about building my lab, books I have read or am reading and issues I run into with CCIE-related lab tasks, etc, etc. Hope you enjoy!
Subscribe to:
Posts (Atom)