Subnetting Made Easy And Other Cisco Tidbits

"ip classless" versus "no ip classless"
Tuesday, 9 June 2009

This often has me confused but the article below, rejigged slightly from the original article here seems to have cleared the fog from my mind and hopefully yours too.

Where the ip classless configuration command falls within the routing and forwarding processes is often confusing. In reality, IP classless only affects the operation of the forwarding processes in IOS; it doesn't affect the way the routing table is built. If IP classless isn't configured (using the no ip classless command), the router won't forward packets to supernets. As an example, let's place three routes in a routing table and route packets through the router.

Note: If the supernet or default route is learned via IS-IS or OSPF, the no ip classless configuration command is ignored. In this case, packet switching behavior works as though ip classless were configured.

router# show ip route
....
172.30.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.30.32.0/20 [90/4879540] via 10.1.1.2
D 172.30.32.0/24 [90/25789217] via 10.1.1.1
S* 0.0.0.0/0 [1/0] via 10.1.1.3

Remembering that the 172.30.32.0/24 network includes the addresses 172.30.32.0 through 172.30.32.255, and the 172.30.32.0/20 network includes the addresses 172.30.32.0 through 172.30.47.255, we can then try switching three packets through this routing table and see what the results are.

A packet destined to 172.30.32.1 is forwarded to 10.1.1.1, since this is the longest prefix match.

A packet destined to 172.30.33.1 is forwarded to 10.1.1.2, since this is the longest prefix match.

A packet destined to 192.168.10.1 is forwarded to 10.1.1.3; since this network doesn't exist in the routing table, this packet is forwarded to the default route.

A packet destined to 172.30.254.1 is dropped.

The surprising answer out of these four is the last packet, which is dropped. It's dropped because its destination, 172.30.254.1, is within a known major network, 172.30.0.0/16, but the router doesn't know about this particular subnet within that major network.

This is the essence of classful routing: If one part of a major network is known, but the subnet toward which the packet is destined within that major network is unknown, the packet is dropped.

The most confusing aspect of this rule is that the router only uses the default route if the destination major network doesn't exist in the routing table at all. However, if ip classless was configured the default route would have been used.

So there you have it. The fundamental difference between the configuration of ip classless and no ip classless is whether the default route would be used.

Posted byChris Bloomfield at 14:25 2 comments  

Labels: Cisco, default route, ip classless, no ip classless

Summary Route to Null0 - Routing Loop Prevention

Why is that when we summarise networks we see a static summary route automatically generated to Null0?

Let's assume for a minute that we didn't have this static route automatically generated for us and consider the following example.

I have a router R1 that has subnets 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24, 192.168.4.0/24, and 192.168.5.0/24 and I decide that R1 should advertise these routes in one summary route to its neighbour at R2 via R1s Serial0/0 interface. As I am using one summary route I could summarise them down to 192.168.0.0/21 which covers 192.168.0.0 to 192.168.7.255. I also have a default route configured on R1 which points all unmatched traffic out of Serial0/0 (ip route 0.0.0.0 0.0.0.0 Serial0/0).

Now let's say that R2 receives a packet destined for 192.168.6.1/24. It will look into its routing table and see that there is a route to 192.168.0.0/16 via R1 which is the summary route sent by R1. R2 forwards this packet to R1 and then what happens? R1 has entries for 192.168.1.0 - 192.168.5.0 in its routing table but no entry for 192.168.6.0/24. So then what does it do? Remember there is a default route configured on R1 pointing to R2 so it will forward the packet back to R2. R2 will look into its routing table and forward it back to R1 ad infinitum. What we have here is a routing loop.

This is why we have the automatically generated summary route to Null0. In our example above the IOS would have generated the following entry in our routing table:

192.168.0.0/21 is a summary, 00:00:05, Null0

Now there is a route for 192.168.6.0 to 192.168.7.255 which will go to Null0 (i.e. be dropped) instead of following the default route, and in this example, creating a routing loop. All of this could be avoided by not oversummarising.

Posted byChris Bloomfield at 13:48 3 comments  

Labels: default route, Null0, static route, summary routes

Index

Follow the links below to find the main articles on this site:

95th Percentile - How ISPs charge
Access Lists vs Prefix Lists
Cabling Cisco devices
Calculate Multicast MAC Address
CCIE - Warm-Up Phase - BGP
CCIE - Warm-Up Phase - Multicast
CCIE - Warm-Up Phase - OSPF
CCNP Training in the UK
Enhanced Interior Gateway Protocol (EIGRP)
Frame Relay - CIR, Bc, Tc
Frame Relay - BECN/FECN
GNS3 Configuration Guide (Linux)
GNS3 Configuration Guide (Windows)
GNS3 PEMU Configuration Guide
GNS3 VPCS Configuration Guide
How to calculate a wildcard mask
"ip classless" versus "no ip classless"
MPLS Command Memoriser Review
Multicast RPF
NAT In A Nutshell
OSPF and Frame Relay
PPP Authentication - AAA
PPP Authentication - PAP and CHAP
PPPoE Server and Client
QoS - Bandwidth, Bandwidth Percent, Bandwidth Remaining Percent
RIP - Routing Information Protocol
RIP - Adjusting timers
Route Maps and Access Lists
Route Summarization - Easy Networks
Route Summarization - Complex Networks
Summary Route to Null 0 - Routing Loop Prevention
Subnetting Made Easy - Critically Acclaimed!
VLAN Trunking - Which combination forms a trunk?
Vyatta on VM Workstation

Posted byChris Bloomfield at 13:41 0 comments  

Labels: best ccnp training, best subnetting guide, ccnp training uk, Cisco, gns3, index, Subnet, subnetting made easy

RIP - Routing Information Protocol
Monday, 8 June 2009

Whether you are taking ICND1, CCNA, CCNP, CCDA, CCIE etc you should all know about RIP. It is very rare for me to come across RIP in my day-to-day work hence I tend to forget some of the nuances behind it. I will focus on RIPv2 but will touch upon RIPv1 in terms of comparison.

Metric

RIP is a distance vector protocol which uses the notion of hop counts as its metric with any one router up to a maximum of 15 hops away from another router. What this means is that if there is a network that is 16 hops or more away from your RIP router and your entire routing domain is running RIP you won't be able to reach that network. It therefore means that RIP is not suitable for large networks. RIPv1 and v2 both use the same maximum hop count as their metric.

Classful and Classless behaviour

RIPv1 is classful and RIPv2 is classless. What this means in very simple terms is that RIPv1 does not send the subnet mask in its routing updates whereas RIPv2 does and as such RIPv2 supports Variable Length Subnet Masks. If a router running RIPv1 has a different class of address on two interfaces (e.g. a Class A address on one interface and a Class B address on another interface) an update going out of the Class B interface will automatically summarise the Class A networks in that update to the default mask of /8. For example, the router may have learned about 10.1.2.0/24 on one interface but because it is advertising that network out of an interface with a different class of address it would advertise it as 10.0.0.0/8. This doesn't happen with RIPv2 as you can issue the no auto-summary command under the routing process and the router will advertise 10.128.1.0/24. This is especially important when it comes to discontiguous networks which is a fancy name for a class of network that has another class of network in between, for example:

(Class A)R1(Class B)-->(Class B)R2(Class B)-->(Class B)R3(Class A)

Here R2 could learn a route to 10.0.0.0/8 from both R1 and R3 as both R1 and R3 would have automatically summarised the Class A address to a /8.

A point that is often overlooked with RIP is the behaviour when the same class of address is used throughout. If my router had an interface with a Class A address but with a non-Class A subnet mask (e.g. 10.1.2.0/24) and I received an update about 10.1.3.0/24 through that interface, the RIP router would assume that it should apply the mask configured on that interface (i.e. a /24) and not the default Class A mask of /8.

Basic Configuration

Always advertise the classful network so if you want to advertise 10.1.2.0 you only need to specify 10.0.0.0 in the network command.

conf t
router rip
version 2 <--RIPv2 enabled
network 10.0.0.0
no auto-summary <--turn off automatic summarisation (I do this as a matter of course)

What does the network command tell the router to do? In RIP it tells the router to do three things:

1. Advertise all networks that form part of the subnet specified
2. It tells the router to listen to RIP updates on the interfaces with IP addresses in that configured subnet.
3. It tells the router to send RIP updates out of the interfaces with IP addresses in that configured subnet.

Passive Interface

The passive-interface command tells a router's interface to stop sending updates out of that interface. Note here that the interface will still receive RIP updates because it never forms neighbour adjacencies, and just receives information from other RIP routers.

router rip
version 2
network 10.0.0.0
no auto-summary
passive-interface FastEthernet0/0 <--stops RIP sending updates out of fa0/0

Be aware that you can make all interfaces passive by issuing the passive-interface default command. This might be desirable when you want all interfaces except one from sending updates. For example, you may only want fa0/0 sending RIP updates so you make every interface passive by default and then issue the no passive-interface [interface] command:

router rip
version 2
network 10.0.0.0
no auto-summary
passive-interface default <--stops RIP updates from being sent out of all interfaces
no passive-interface FastEthernet0/0 <--allows RIP updates to be sent out of that interface

How do we stop updates from being received?

As we have seen the passive-interface command tells our router to not send RIP updates out of the specified interface but that same interface can still receive RIP updates. In order to prevent updates from being received you should use something called a distribute-list. A distribute-list filters out routes from entering the routing table by referencing a pre-configured access-list or prefix-list.

For example, let's create an access-list:

access-list 1 permit any

The syntax of a distribute-list when using an access-list is as follows and is configured under the routing process:

distribute-list [access-list-number_or_access-list-name] [in | out] [interface]

If there is a match with a deny statement in the access-list then that route is filtered out of the routing update. If you look at my access-list you will see that I am, in effect, matching everything in my access-list so all routes should be filtered out.

Using the earlier configuration example, I will use a distribute-list to stop updates being received on fa0/0 and passive-interface from sending updates out of fa0/0.

access-list 1 deny any

router rip
version 2
network 10.0.0.0
no auto-summary
passive-interface FastEthernet0/0 <--stops RIP sending updates out of fa0/0
distribute-list 1 in FastEthernet0/0 <--filter incoming updates on fa0/0 as specified by ACL 1

You could replace the passive-interface command with a distribute-list. To do this make sure your access-list permits everything as in my preconfigured ACL 1 and apply it outbound on the outgoing interface:

access-list 1 permit any
router rip
version 2
network 10.0.0.0
no auto-summary
distribute-list 1 in FastEthernet0/0 <--filter incoming updates on fa0/0 as specified by ACL 1
distribute-list 1 out FastEthernet0/0 <--filter outgoing updates on fa0/0 as specified by ACL 1

Administrative Distance (AD)

RIP has an AD of 120. Cisco uses AD as a measure of trustworthiness about a certain route. If there are two routes to the same network learnt by different routing protocols then the AD is used as a tiebreaker. The routing protocol with the lowest AD is considered to be more trustworthy and the route learned from that routing protocol will be installed into the routing table. Below are some of the ADs of static routing and routing protocols:

Connected Interface = 0
Static route = 1
EIGRP Summary = 5
eBGP = 20
Internal EIGRP = 90
IGRP = 100
OSPF = 110
ISIS = 115
RIP = 120
EGP = 140
ODR = 160
External EIGRP = 170
iBGP = 200
Unknown = 255

Looking at those ADs, RIP is not a terribly trusted protocol and equivalent routes learned by static, eBGP, Internal EIGRP, IGRP, OSPF, and ISIS would be installed in the routing table before a RIP route. Of course you can change the AD of a routing protocol by issuing the distance command under the routing process:

router rip
version 2
distance 90

Interestingly if you set the distance to 255 no routes learned by that routing protocol will be installed in the routing table.

Sending Updates

RIPv1 broadcasts its routing updates to 255.255.255.255 whereas RIPv2 multicasts its updates to 224.0.0.9. Both use UDP Port 520 at the Transport Layer. A router's full routing table is sent every 30 seconds to the IP address above depending on whether v1 or v2 is used. There are also triggered updates which are sent when a route in a router's routing table changes.

When a router sends its update it adds 1 to the metric of each route it is advertising so that receiving routers know the metric to get to that route. For example, if a router had a route to 192.168.1.0/24 with a metric of 2 , it would advertise it with a metric of 3.

Sending and Receiving version on interfaces

By default a RIP router will send only v1 updates out of an interface but receive both v1 and v2 updates. This allows for a mix of v1 and v2 capable routers. If your router is running RIPv2 it can only send and receive v2 updates only. You can configure it yourself under an interface:

interface Fastethernet0/0
ip rip receive version [1 | 2 | 1 2]
ip rip send version [1 | 2 | 1 2]

Timers

It is worth fully understanding how the timers in RIP work and what their default values are. They are:

Update Timer = 30 seconds
Invalid Timer = 180 seconds
Holddown Timer = 180 seconds
Flush Timer = 240 seconds

When a route is learned via RIP the Invalid and Flush timers are started for that route and are reset when that route is learned again. In normal operation this should be every 30 seconds as the router that has advertised this route should be sending their update every 30 seconds as dictated by the Update Timer. If there is a failure in the network that stops updates about this route from being received from the original advertising router, the Invalid and Flush timers will count up over 30 seconds towards 180 and 240 seconds respectively. If during that time our router learns the same route but from a different source and it has a worse metric (i.e. the hop count is greater than our current route) it won't install that update in its routing table until the original route is flushed. Once the Invalid Timer reaches 180 seconds the Holddown Timer starts counting down from 180 seconds with the Flush Timer only having 60 seconds left as it has already been running for 180 seconds. The route in the routing table will now show something like this:

R 192.168.1.0/24 is possibly down

Whichever is the first out of the Holddown and Flush timers to expire will cause the route to be removed/flushed from the routing table. By default this will always be the Flush timer as it has only 60 seconds left to elapse once the Invalid Timer reaches 180 seconds. Your router can now install previously heard updates that originally had a worse metric once those updates have been received again. You can quickly see why RIP has slow convergence time and would have to wait 240 seconds for the old route to be flushed and could wait for another 30 seconds to receive an update if one exists. That's 270 seconds, or three and a half minutes, which is bloody slow and it could be longer! You can adjust your timers using the timers basic update invalid holddown flush under the routing process:

router rip
version 2
timers basic 30 90 120 120

This sets the Update Timer to 30 seconds, Invalid Timer to 90 seconds, and both the Flush and Holddown Timers to 120 seconds.

Neighbour relationship

RIP has absolutely no concept of neighbours. It simply listens to updates from other routers and it never, ever, ever, sends Hellos, ok? This is what is meant when you hear the term "routing by rumour".

Split Horizon

Split Horizon stops a network being advertised out of an interface in which it has been learned. For example, if a router learned about network 192.168.1.0/24 on fa0/0 a RIP routing update out of fa0/0 would not contain 192.168.1.0/24. This is to prevent routing loops from occurring. Split Horizon is enabled by default on all interfaces except Frame Relay interfaces where the IP address is configured on the physical interface. You can turn off Split Horizon on an interface by issuing the no ip split-horizon command under an interface:

interface FastEthernet0/0
no ip split-horizon

Interestingly there is a special case where Split Horizon is overridden and that is called Poison Reverse. This is where a router receives an update on an interface specifying that a route is down, as indicated by a hop count of 16 (known as route poisoning), and the receiving router sends that update back out of the same interface. If you run a debug on RIP (debug ip rip) you will see Poison Reverse in action with a line of:

RIP: sending v2 flash update to 224.0.0.9

These flash updates are also seen in triggered updates.

Authentication

RIPv2 allows for passwords to be exchanged between RIP routers to secure updates and stop rogue RIP routers from being deployed in a network and disrupting it.

By default, RIP passwords are sent in plain-text but you can configure it to use MD5 which I would highly recommend if your network is susceptible to eavesdropping. In fact I would do it as a matter of course. As you would expect, the passwords on both sides must match in order for the RIP updates to be successfully exchanged.

You configure the passwords in global configuration mode using key-chains which are made up of keys which in turn have the password configured on them with optional send and receive lifetimes. Let's configure a basic key-chain (more advanced configuration can be seen here):

key-chain MyKeyChain
key 1
key MyPassword

To turn RIP authentication on you must configure it under the interface which will be sending the updates:

int fa0/0
ip rip authentication key-chain [key-chain-name]

So for my example it would be:

int fa0/0
ip rip authentication key-chain MyKeyChain

If you want to send your passwords in plain-text that is all there is to it as you remember RIP defaults to using plain-text passwords. You can specifically tell RIP to send passwords as plain-text by issuing the ip rip authentication mode text command under your outgoing interface as in:

int fa0/0
ip rip authentication mode text
ip rip authentication key-chain MyKeyChain

If you want to use MD5 instead then guess what one word needs to change in the example above? Yes, you've got it, replace the word "text" with "md5" as in:

int fa0/0
ip rip authentication mode md5
ip rip authentication key-chain MyKeyChain

Remember you have to explicitly set the authentication mode to MD5 as RIP defaults to using plain-text passwords.

Changing the next-hop router

Did you know that a RIP router can send updates about a route and change the next-hop router? As you would imagine, if a router, say R1, was to learn a route from R2, R1 would use R2 as the next-hop. R2, however, could conceivably change the next-hop from itself to another router.

In RIPv2, each RIP entry includes a space where an explicit IP address can be entered as the next hop router for datagrams intended for the network in that entry. This feature can help improve efficiency of routing by eliminating unnecessary extra hops for packets sent to certain destinations.

One common use of this field is when the most efficient route to a network is through a router that is not running RIP. Such a router will not exchange RIP messages and would therefore not normally be selected by RIP routers as a next hop for any network. The explicit Next Hop field allows the router to be selected as the next hop regardless of this situation.

The Next-Hop field is changed by using route-maps.

Using Offset Lists to change RIP's metric for a particular route

You change the metric received or advertised in RIP by using an offset-list. This is very similar in configuration to distribute-lists where you reference an access-list. The access-list will be checked against sent or received updates and the specified offset added to the metric. The basic syntax is:

offset-list [access-list-number_or_access-list-name] [in | out] [specified-offset] [interface]

Let's look at an example:

R1 has a route for 192.168.1.0/24 with a hop count of 0 as it is directly connected. We want to advertise that route to R2 with a hop count of 2. Remember that a RIP router will advertise out its hop count + 1 to other RIP routers so R2 would ordinarily receive a hop count of 1 to reach 192.168.1.0/24 via R1. Let's configure our offset-list:

access-list 1 permit 192.168.1.0 0.0.0.255

router rip
offset-list 1 out 1 FastEthernet0/0

Here offset-list 1 specifies ACL 1 which will match 192.168.1.0/24. This is applied outbound as specified by out. We add 1 to the metric of all routes matched by our access-list as specified by the 1 after the out keyword. Finally we specify the interface out of which our offset-list is applied.

Clearing RIP routes from the routing table to speed up convergence

As RIP has no concept of neighbours you can simply issue the clear ip route * command from privileged mode. This will clear out all routes and cause the router to send out RIP request packets. This wouldn't work with a routing protocol that has neighbours such as EIGRP as the routes are promoted to the routing table from the topology table. In that case you would have to tear down the neighbour adjacency.

Conclusion

I've tried to be as brief as possible as I don't see the point of reinventing the wheel as there are so many quality papers on RIP. I hope I've got enough detail in here for you to understand the basic operation of RIP and some of the extras that can be configured.

As always, if you have any questions about this topic please feel free to leave a comment and/or email me using the Contact Me tab at the top of the screen.

Good luck with your studies!

Posted byChris Bloomfield at 19:07 4 comments  

Labels: Cisco, RIP, RIPv1, RIPv2, Routing Information Protocol

Route Maps and Access-Lists
Sunday, 7 June 2009

I received an email from one of the readers, Joel, who is getting confused as to how access-lists and route-maps work together. I have therefore created this topic to cover the very basics of access-lists and how they link into route-maps. In turn I have expanded the lesson on route-maps to cover a little more of the nuances of route-map theory as well as an aid to other readers.

Access-lists contain very simple logic. Lists 1-99 (standard access-lists) will permit or deny all IP traffic from a particular source whereas access-lists 101-199 (extended access-lists) extend this functionality allowing you to permit/deny with more granularity, for example, specifying both source and destination address, Layer 4 protocols and port number (i.e. TCP/UDP), and Layer 3 protocols other than IP (i.e. ICMP).

The syntax for standard access-lists is as follows:

"I wish to permit all IP traffic from host [host-ip-address]"
"I wish to permit all traffic from [subnet] [wildcard-mask]"
"I wish to deny all IP traffic from host [host-ip-address]"
"I wish to deny all traffic from [subnet] [wildcard-mask]"

An example is you want to allow all IP traffic from 192.168.1.0/24. The access-list is simple:

access-list [1-99] permit 192.168.1.0 0.0.0.255

The syntax for extended access-lists is slightly different:

"I wish to [permit/deny] [type-of-traffic] going from [source-address] [source-wildcard-mask] to [destination-address] [destination-wildcard-mask] [optional port-number]"

Let's say you would like to permit all Telnet traffic going from 192.168.1.0/24 to a device at 192.168.2.1.

Telnet uses TCP port 23 and here is how you would write the extended access-list:

"access-list [101-199] permit tcp 192.168.1.0 0.0.0.255 host 192.168.2.1 eq 23"

In English, this access-list permits TCP from 192.168.1.0/24 to the host whose address is 192.168.2.1 where the TCP port number is 23.

How to apply access-lists to route-maps

Believe me there is nothing tricky about doing this. A route-map is a way of influencing the routing decision made by a routing device. The basic syntax of a route-map is as follows:

route-map [route-map-name] [permit/deny] [sequence-number]
match [condition]
set [what-you-want-to-do-with-the-packet-if-it-matches-the-match-criteria]

As you build up your route-map you simply increase the sequence number for each match you want to do. Once you have created your route-map you must then apply it to a router interface e.g.

int fa0/0
ip policy route-map [route-map-name] [in/out]

Let's step back up to the match criteria. There are a number of things that we can match on but what we will focus on is how we can influence traffic flows through a router. We do this by using the match ip address [access-list-number] command. The extended access-list in my earlier example called for allowing Telnet traffic from 192.168.1.0/24 to be able to reach host 192.168.2.1. Let's take that example a bit further and say that we want to make all Telnet traffic going from 192.168.1.0/24 to host 192.168.2.1 which has entered my router's fa0/0 interface to leave my router's Serial0/0 interface. We could use that access-list and apply it to our route-map (I've called it MYMAP):

access-list 101 permit tcp 192.168.1.0 0.0.0.255 host 192.168.2.1 eq 23

route-map MYMAP permit 10
match ip address 101 <---this line refers to access-list 101
set interface Serial0/0

int fa0/0
ip policy route-map MYMAP in <---applies the MYMAP route-map inbound on fa0/0

How does the router service the route-map?

Actually it is very logical. The router starts at the lowest sequence number until it finds a match.

So let's run through it. A host at 192.168.1.1 tries to Telnet to 192.168.2.1 and the packet is received on fa0/0 of our router. Our router, looking at fa0/0, realises that policy-based routing is required and that it should look at the route-map named MYMAP in order to make a decision on how to forward the traffic. The router starts at the lowest sequence number in the route-map and checks the match criteria. The example above tells the router to check access-list 101. The packet received matches access-list 101 so the router returns to the route-map and checks what the set command tells it to do. The set command tells it to forward this traffic out of Serial0/0

What if there is no match found?

If there is no match then the router will route the packet based on the contents of the routing table. If a host at 192.168.3.1 tried to Telnet to 192.168.2.1 and the packet is received through fa0/0 of our router, the router will look into MYMAP, then at access-list 101, realise that access-list 101 does not match 192.168.3.1 as a source address and will return to the route-map looking for the next highest sequence number. In our example there is not another sequence number so the router will simply forward the traffic based upon the contents of its routing table (i.e. what it would do if there was no route-map applied to the fa0/0 interface).

How could we use route-maps to drop traffic?

Chris, you've just told us that if no match is found then the packet will be forwarded by the contents of the routing table so how can I influence that?
Generally, you would drop traffic on an interface using an access-list applied directly to the interface, however, it can be done using a route-map. Let's say you want to have control over all traffic coming in on fa0/0 of our router and want to drop anything that doesn't match our defined criteria. Let's say I have created access-lists 101-105 which specifies my criteria. My route-map would look as follows:

route-map MYMAP permit 10
match ip address 101 <---this line refers to access-list 101
set interface Serial0/0
route-map MYMAP permit 20
match ip address 102 <---this line refers to access-list 102
set interface Serial0/1
route-map MYMAP permit 30
match ip address 103 <---this line refers to access-list 103
set interface Serial0/2
route-map MYMAP permit 40
match ip address 104 <---this line refers to access-list 104
set interface Serial0/3
route-map MYMAP permit 50
match ip address 105 <---this line refers to access-list 105
set interface Serial0/4

Now I want to deny everything else. Remember the Null0 interface, what I like to call Packet Heaven (as that is where packets that need to be dropped/die go)? Check this route-map statement out:

route-map MYMAP permit 60
set interface Null0

Whoa Chris! What did you do there? Where has the match statement gone? The beauty is you don't need it. Sure, you could configure an access-list (e.g. access-list 106 permit ip any any) and have:

route-map MYMAP permit 60
match ip address 106
set interface Null0

But there really is no need. If the route-map evaluation has got this far we are just saying "drop everything else, send it to Packet Heaven, Null0". By removing the match statement you are in effect creating a catch-all statement. Equally, you may have wanted all traffic not matching access-lists 101-105 to be routed out of Serial0/5 rather than be routed using the routing table or dropped. Your last route-map clause would have been:

route-map MYMAP permit 60
set interface Serial0/5 <-- all traffic not previously matched will go via Serial0/5

Other Key Points About Route-Maps

1. The route map statements can also be marked with a deny. If the statement is marked as a deny, the packets meeting the match criteria are sent back through the normal forwarding channels (in other words, destination-based routing is performed). Only if the statement is marked as permit and the packets meet the match criteria are all the set clauses applied. If the statement is marked as permit and the packets do not meet the match criteria, then those packets are also forwarded through the normal routing channel.

2. There can be multiple match criteria on the same line where only ONE of the criteria has to match. There can be multiple match statements on different lines where ALL match statements must match. I think an example here is in order:

route-map MYMAP permit 10
match ip address 101 102 103 104
match ip address 105
set interface Serial0/0

The logic here works thus:

match ip address 101 OR 102 OR 103 OR 104
AND
match ip address 105

So a packet comes in and matches access-list 104, the router then goes on to check access-list 105. If the received packet also matches access-list 105 then the set command is used. If the packet had failed to match access-list 105 then the next statement in the route-map would be evaluated or the packet would be forwarded normally.

3. There are other match criteria such as packet length but I'll focus on the other set criteria.

set ip next-hop [next-hop-ip-address] - specifies where to send the packet. Preferable to use this rather than exit interface.

set default interface [interface] - If there is no entry in the routing table for the destination of this packet route it through the specified interface

set default ip next-hop [next-hop-ip-address] - if there is no entry in the routing table for the destination of this packet route it via the specified next-hop

Notice the use of the "default". This is only true if there is no corresponding entry in the routing table.

4. Like match statements, you can have multiple set statements too. Again, an example will help illustrate this.

route-map MYMAP permit 10
match ip address 101
set interface Serial0/0 Serial0/1

By default any matches to access-list 101 will exit Serial0/0 but if that fails Serial0/1 will be used as the exit interface.

Conclusion

Like everything, route-maps are easy once you understand how the syntax works. Any questions or feedback please feel free to leave comments and/or email me using the Contact Me tab at the top of the screen. Good luck to you all in your studies!

Posted byChris Bloomfield at 18:07 16 comments  

Labels: access, access-lists, Cisco, extended, network, Route Summarization, route-map, route-maps, standard

Vyatta on VM Workstation
Monday, 15 December 2008

Here's the deal. How do you fill your work time looking busy but having a bit of fun? Simple. Look out for emerging technologies and tell your department you want to "innovate" with Product X. So here I am, looking at Vyatta. Bold claims from these guys but is it as good as they say? Well I'm not here to run the mathematical experiments. What I want to know is "Is it easy to use?" and "Can I use it in one of our projects?". It's early days to be answering the latter but I may be able to answer the former over a series of posts.

What I want to do is set up a dummy network in VM Workstation to simulate a square with a Vyatta router at each corner like so:

Vyatta Instance 1 --> Vyatta Instance 2
Vyatta Instance 1 --> Vyatta Instance 3
Vyatta Instance 2 --> Vyatta Instance 4
Vyatta Instance 3 --> Vyatta Instance 4

I really am a noob to VM Workstation but after a little playing around I got it to work.

Taking the above connections I used the Custom Network Connections for each (I believe VMNet0 and VMNet1 are reserved):

Vyatta Instance 1 --> Vyatta Instance 2 = VMNet2
Vyatta Instance 1 --> Vyatta Instance 3 = VMNet3
Vyatta Instance 2 --> Vyatta Instance 4 = VMNet4
Vyatta Instance 3 --> Vyatta Instance 4 = VMNet5

By default each virtual machine in VM Workstation has one Network Connection set up (usually NAT). Modify this to a custom connection and from the drop-down list choose the appropriate VMNet. To add a new Network Adapter simply click Add in the Virtual Machine Settings and choose Network Adapter then select Custom and choose the desired VMNet connection. For my example above I modified the first Network Adapter on Vyatta Instance 1 to VMNet2 and created a new Network Adapter in VMNet3. I done similar on the other three instances and lo-and-behold everything was connected.

Here's my basic settings:

Vyatta Instance 1:

configure
set system host-name Vyatta-Instance-1
set interfaces ethernet eth0 description Link_To_Vyatta_Instance_2
set interfaces ethernet eth0 address 192.168.2.1/24
set interfaces ethernet eth1 description Link_To_Vyatta_Instance_3
set interfaces ethernet eth1 address 192.168.3.1/24
commit
save

Vyatta Instance 2:

configure
set system host-name Vyatta-Instance-2
set interfaces ethernet eth0 description Link_To_Vyatta_Instance_1
set interfaces ethernet eth0 address 192.168.2.2/24
set interfaces ethernet eth1 description Link_To_Vyatta_Instance_4
set interfaces ethernet eth1 address 192.168.4.1/24
commit

Vyatta Instance 3:

configure
set system host-name Vyatta-Instance-3
set interfaces ethernet eth0 description Link_To_Vyatta_Instance_1
set interfaces ethernet eth0 address 192.168.3.2/24
set interfaces ethernet eth1 description Link_To_Vyatta_Instance_4
set interfaces ethernet eth1 address 192.168.5.1/24
commit

Vyatta Instance 4:

configure
set system host-name Vyatta-Instance-4
set interfaces ethernet eth0 description Link_To_Vyatta_Instance_2
set interfaces ethernet eth0 address 192.168.4.2/24
set interfaces ethernet eth1 description Link_To_Vyatta_Instance_3
set interfaces ethernet eth1 address 192.168.5.2/24
commit

This is probably more for my reference but to undo anything use the "delete" command. For example if I accidentally put an IP address under eth0 for example I could use the following;

delete interfaces ethernet eth0 address 192.168.3.1/24

Now I've decided to run RIP just to see how easy it is.

Vyatta Instance 1

configure
set protocols rip network 192.168.2.0/24
set protocols rip network 192.168.3.0/24
commit
save

Vyatta Instance 2

configure
set protocols rip network 192.168.2.0/24
set protocols rip network 192.168.4.0/24
commit
save

Vyatta Instance 3

configure
set protocols rip network 192.168.3.0/24
set protocols rip network 192.168.5.0/24
commit
save

Vyatta Instance 4

configure
set protocols rip network 192.168.4.0/24
set protocols rip network 192.168.5.0/24
commit
save

To shut down an interface:

set interfaces ethernet eth0 disable

To bring it back up:

delete interfaces ethernet eth0 disable

It all seems easy so far.

Posted byChris Bloomfield at 11:23 1 comments  

Labels: Cisco, machine, virtual, VM workstation, VMware, vyatta

GNS3 Configuration Guide - Linux (Fedora 9)
Thursday, 4 December 2008

I've been hearing how much better Linux is to Windows from guys across the world so I thought I would install FC9 on my home computer and promptly destroyed Windows XP. What a blessing in disguise! Now I've made the leap of faith I am one happy man although still a little green to the world of Linux.

Let's get to installing GNS3, VPCS, loopback adapter equivalent bridge interfaces etc. I'm going to do this without pictures as for the majority of the case it is exactly the same as the Windows installation. It is just the initial installation and dependencies that are required.

Note to purists: I am a Linux noob so if my terminology is out then I apologise.

Note the use of sudo here. If you haven't set it up then you can log in as root and repeat the command (without the "sudo" prefix).

1. Install PyQt4

Fedora = sudo yum -y install PyQt4

Ubuntu = sudo apt-get install PyQt4

This should install all dependencies needed for GNS3 including SIP.

2. Install tunctl and bridge-utils e.g. sudo yum -y install tunctl bridge-utils

This will now allow you to create bridged interfaces equivalent to Microsoft Loopback Adapters.

3. Download GNS3 from here. I tend to go for the tgz file.

4. Download Dynamips from the same location under the heading Associated Software. I run 32-bit only so I download the Dynamips 0.2.8-RC2 binary for Linux x86 platforms

5. Right-click the downloaded GNS3 file and choose Extract Here. Drag the Dynamips file downloaded in Step 4 to the extracted folder. Now right-click the Dynamips file and select the Permissions tab and ensure the "Allow executing file as program" box is ticked, then click Close.

6. Now double-click the gns3 file and choose Run. Assuming that all dependencies have been installed you should see GNS3 start with the screenshot in Step 3 of my GNS3 Windows guide. Follow the majority of that to set up the images and working directories plus the idlepc value.

So hopefully now you should be able to muck around with GNS3 and do most of what you need to do. However, I had one main issue and that was how do I connect my router to my local machine so that I could run syslog servers, iperf, and other apps like we do using the Loopback Adapter in Windows? Well I have to pay my respects to tuner_x at the Sadikhov IT forums for the guide on how to do this. You must run GNS3 as root in order to achieve this so for example I run:

sudo ./Chris/Desktop/GNS3-0.5-src/gns3

NOTE: If Dynamips doesn't start (you'll probably notice that you cannot connect to a hypervisor on 7200 when dragging a router onto the stage) as root then you need to either clean the working directory as it points to your user account or point the working directory to a new location.

1. If you didn't do this before you need to install tunctl and bridge-utils as outlined in Step 2 of the initial configuration guide above.

2. Now add the following to the script below so each time you switch on your PC the bridge interfaces are created.

sudo vi /etc/rc5.d/S99local

Now insert the following (note that there is no particular naming convention, just what I chose to do) and save:

# Script to create bridge interfaces. Requires tunctl and bridge-utils to be
# installed.
#
# This creates the interfaces. -t names the interface and -u sets the owner of
# of the interface.

/usr/sbin/tunctl -t fed_0 -u Chris
/usr/sbin/tunctl -t fed_1 -u Chris
/usr/sbin/tunctl -t gns3_0 -u Chris
/usr/sbin/tunctl -t gns3_1 -u Chris

# Then bring the interfaces up

/sbin/ifconfig fed_0 up
/sbin/ifconfig fed_1 up
/sbin/ifconfig gns3_0 up
/sbin/ifconfig gns3_1 up

# Now create the bridge interface

/usr/sbin/brctl addbr gns3_br0
/usr/sbin/brctl addbr gns3_br1

# Bring the bridge interfaces up
/sbin/ifconfig gns3_br0 up
/sbin/ifconfig gns3_br1 up

# Add the tap interfaces to the bridge interfaces
/usr/sbin/brctl addif gns3_br0 fed_0
/usr/sbin/brctl addif gns3_br0 gns3_0

/usr/sbin/brctl addif gns3_br1 fed_1
/usr/sbin/brctl addif gns3_br1 gns3_1

# Here is an example of how to assign an IP address to the gns3_br0 interface so one
# can ping from a GNS3 router to the local machine in order to run syslog etc
#
# ifconfig gns3_br0 inet 192.168.2.254 netmask 255.255.255.0 up
#
# I do this manually and not via the script but keep it here for reference only.
# And that's it

Now you could choose to reboot or restart the appropriate services. I tend to restart the services as it is quicker than rebooting.

sudo /etc/rc5.d/S99local restart
sudo /etc/init.d/network restart

Now add an IP address to one of your gns3 bridge interfaces. Here I am using the first:

sudo ifconfig gns3_br0 inet 192.168.2.254 netmask 255.255.255.0 up

NOTE: Do not use the same IP address as your main ISP router otherwise you'll knock out your Internet connection. D'oh! Always learn the hard way don't you Chris? LOL.

Go into GNS3 and drag a cloud, or a customised symbol, onto the stage and right-click and choose Configure. Select the "NIO TAP" tab and type the name of your bridge interface (e.g. gns3_br0) then click Add, Apply, then OK.

Hook your router up to the cloud, start the IOS, console into your router, and put the interface into the same subnet as your bridge interface. Bring the interface up and lo-and-behold you should have connectivity between your PC and your router.

What about multiple hosts? You can still use VPCS as explained in my VPCS Configuration Guide for Windows although there is a slightly different way to run it.

1. Once you have downloaded the file, extract it to your GNS3 folder.

2. Now open the extracted folder and locate the "vpcs" file (NOT vpcs.exe).

3. Right-click the vpcs file and choose the Permissions tab and tick the box next to "Execute".

4. Go to the desktop and right-click and choose Create Launcher.

5. Type = Application in Terminal

6. Name = VPCS

7. Command = the path to the vpcs file located in Step 2.

8. Comment = Virtual PCs

9. Click OK to create the launcher

10. Drag the launcher into the VPCS folder.

When you want to run VPCS just double-click on the created launcher. The configuration works just as it does in Windows.

That's it. FC9 running GNS3 exactly as I had it on Windows.

I hope it helps you Linux noobs to run GNS3.

Chris

Posted byChris Bloomfield at 13:36 3 comments  

Labels: brctl, bridge-utils, dynamips, FC9, Fedora, Fedora 9, gns3, linux, tunctl, vpcs