Saturday, July 10, 2010

Internal Router Switching



Something that's over looked during CCNA/CCNP studies is the actual switching that's done on the router. Of course the switching a router does and the switching done on an actual switch is completely different. When speaking of switching on a router it deals with the process of forwarding a packet from one interface on the router to another interface on the same router. This process can be extremely CPU intensive for the router to do. However with the use of certain router switching tecnologies such as "Fast Switching" and Cisco Express Forwarding (CEF) you can significanlty decrease the amount of work the router's CPU has to do.

In the lab I created, I told the internal router to ping the "website" router with 1000000 packets (to simulate traffic). While doing this I disabled CEF and Fast Switching note what happened below:


Note that each exclamation point means that the packet was successfully forwarded and that each period means that the packet was dropped. Looking near the end of the picture you can see when I disabled CEF and the packets were too processor intensive for the router to handle and queue so it started dropping packets to keep up with demand. For testing purposes I increased the packet size to help bog down the router so that you can see the example shown.

Saturday, June 26, 2010

Configuring HSRP Protocol


I spent a little time this morning learning about the HSRP (Hot Standby Router Protocol) and how to configure it in a real world environment. This is something that I might think about implementing in our networking system actually. It works by creating redundancy between two routers in case one router loses internet connectivity, the other router can take over. The configuration was rather simple and easy to understand. You're basically creating a virtual IP (VIP) that your internal network will use rather than the routers actual Ethernet IP address. I have including a sample configuration below:

Router_A#sh run int fa0/0
Building configuration...

Current configuration : 166 bytes
!
interface FastEthernet0/0
ip address 192.168.100.2 255.255.255.0 (actual IP address)
duplex auto
speed auto
standby ip 192.168.100.1 (VIP address configured on Router B as well)

standby preempt (Tells the router to try and become primary when circuit is back up)

standby track Serial0/0 10 (decrements HSRP priority, router with highest is primary router)

end

Sunday, June 20, 2010

Creating GRE Tunnels


Today was a pretty simple lab, I went through the configuration of GRE Tunnels between two different remote locations. GRE configuration is very simple and consists of the following commands on both device:

1. Create the logical tunnel interface on both remote devices:

interface tunnel X

2. Assign an IP address to the tunnel interface:
ip address X.X.X.X subnet mask

3. Point the tunnel towards the source interface:

tunnel source interface

4. Point the tunnel towards the destination interface:
tunnel destination X.X.X.X (remote device ip)

One thing to note when creating tunnels is that the remote destination must be in the routers ip table. That's about it though, you should see your tunnels come right up once everything is configured on both ends. Remember that GRE tunnels are unencrypted so it's best to route the tunnels through some type of security device such as an ASA or even a dedicated VPN concentrator.

Saturday, June 19, 2010

Preventing Redistributed Routing Loops


Today I ran over a quick lab of something you may experience in the real world, routing loops due to redistribution. As shown in the picture above, both the routers R1 and R2 are redistributing the same networks both ways. Because of Administrative Distance, each router would think the best route to EIGRP were through each others OSPF interfaces and vice versa which would cause a routing loop.

To circumvent this, I have created a route-map and assigned tags to both routing networks to prevent redistributed routes to be learned in both directions:

(Running Configurations on Both R1 and R2)
router eigrp 1
redistribute ospf 1 route-map OSPF-to-EIGRP
network 20.0.0.0
default-metric 100000 100 255 1 1500
no auto-summary
!
router ospf 1
log-adjacency-changes
redistribute eigrp 1 subnets route-map EIGRP-to-OSPF
network 10.0.0.0 0.255.255.255 area 0
default-metric 100
!
route-map EIGRP-to-OSPF deny 10
match tag 90
!
route-map EIGRP-to-OSPF permit 20
set tag 110
!
route-map OSPF-to-EIGRP deny 10
match tag 110
!
route-map OSPF-to-EIGRP permit 20
set tag 90

I'm going to be learning about GRE tunnels shortly as well, hopefully it isn't to complicated to grasp, VPN's and tunneling always confused me because I have a habit of over complicating things!

Sunday, June 6, 2010

Lab Portfolio Case Study 1


It took a while but I was able to finally finish the first case study presented in the CCNP Lab Portfolio book. I was rusty on a few topics but I was able to complete the following:

1. Enable EIGRP 1
2. Summarize the 5 loop back address on R2 (not presented in above image)
3. Inject a default route into the EIGRP network pointing towards R3
4. Configure OSPF between R3 and R4
5. Redistribute OSPF into the EIGRP network
6. Inject a default route into the OSPF network pointing towards R3
7. Configure DHCP on the R2 router in order for R3 to gain an IP address on its LAN (Fast Ethernet) interface.

All in all not to bad and it allowed me to brush up on the topics that I always forget! I'm digging pretty deep into my voice studies already. This morning I read through a lengthy overview on the history of Call Manager and VoIP in general. I'll probably finish that up by going through some white papers on IPCC along with the network warrior book.

Friday, June 4, 2010

IPv6 Challenge Lab


I finished today's lab which was a challenge lab, which basically makes you configure the network without any instructions besides IP configuration information. I was able to complete all required tasks successfully which included:

1.Enabling IPv6 EUI-64 between the R3 and R4 routers 2.Enabling EIGRP without auto summarization 3.Creating a manual IPv6 tunnel between the R1 and R3 router 4. Enabling OSPFv3 on all routers using IPv6 (R1,R3,R4)

While I'm about finished with the portfolio book, I'm about to dig even deeper into voice shortly, especially IPCC for my new job. I also picked up the network warrior book and reallly wished I would of had this a year ago, it gives some very good information how a live network operates and what happens in the real world instead of just topics you see on the CCNA.

Saturday, May 29, 2010

IPv6 6to4 Tunnels


Today I configured another type of IPv6 tunnels used to alleviate the headaches of switching to an entirely different IP format in a network! It's called a 6to4 tunnel and it does exactly what the name says. It encapsulates a Ipv6 address within a IPv4 packet so that it can use the IPv6 address locally and still travel across a IPv4 network. Do to the nature of this type of tunnel, it doesn't need to be configured on both ends of the tunnel since it's not considered a point-to-point link. To configure a 6to4 tunnel I used this simple command:

First I configured the logical tunnel:


R1 (config)# interface tunnel 0
R1 (config-if)# tunnel mode ipv6ip 6to4
R1 (config-if)# ipv6 address ipv6 address
R1 (config-if)# tunnel source interface
R1 (config-if)# exit

Second I configured a static route to point towards my tunnel:

R1 (config)# ipv6 route ipv6 address tunnel 0

This tells the router to send this particular IPv6 address out tunnel 0 and tunnel 0 routes this interface out of the source interface.