Archive for February, 2008

Feb
26

Catalyst QoS configuration for IP Telephony endpoints is one of the CCIE Voice labs topics. Many people have issues with that one, because of need to memorize a lot of SRND recommendations to do it right. The good news is that during the lab exam you have full access to the QoS SRND documents and UniverCD content. The bad news is that you won’t probably have enough time to navigate the UniverCD with comfort plus the reference configurations often have a lot of typos and mistakes in them.

Continue Reading

Tags: , , , , , ,

Feb
23

QoS features available on Catalyst switch platforms have specific limitations, dictated by the hardware design of modern L3 switches, which is heavily optimized to handle packets at very high rates. Catalyst switch QoS is implemented using TCAM (Ternary Content Addressable Tables) – fast hardware lookup tables – to store all QoS configurations and settings. We start out Catalyst QoS overview with the old, long time available in the CCIE lab, the Catalyst 3550 model.

Continue Reading

Tags: , , , , , , ,

Feb
22

A common question I get from students is, “when is the best time to take a CCIE bootcamp?” Ideally a bootcamp is taken either  5 to 6 weeks prior to your lab date or the week prior to your lab date.  By taking a bootcamp 5 to 6 weeks prior to your lab date you will have time to reschedule your date if after the bootcamp  you aren’t ready for the real lab.

For the students who take a bootcamp the week prior to their lab date I always recommend to take a couple mock labs 5 to 6 weeks out to see if they are close to being ready for the real lab.  If they are scoring well on the mock labs then I recommend keeping their lab date that is scheduled for the week after the bootcamp.  If they are not scoring well I recommend rescheduling their lab date to at least 4 weeks after the end of the bootcamp.  This means that if after taking the bootcamp they still aren’t ready for the real lab they can reschedule their lab date.  Also I would recommend trying to take time off to study for the last few days leading up to your lab date.   In our last 12 day bootcamp we had a few students pass the lab the following week.  All of them took the days off from work leading up to their lab date.

On a personal note I’m a big advocate of rescheduling a lab date as opposed to just taking the lab if you feel you aren’t ready for it.   Its really easy to see if you are ready for the real lab by just taking a mock lab or two.

Tags: , , , ,

Feb
22

One common problem that causes candidates to fail the CCIE Routing & Switching Lab Exam is the lack of complete IP reachability to various segments used in the network topology. However, due to the short time constraints of the lab exam itself it can be difficult to dedicate enough time to properly verify that reachability exists between all relevant segments. In order to solve this problem two very useful features can be implemented during the lab exam, TCL scripting on the routers and macro scripting on the Catalyst switches.

TCL (Tool Control Language) is a scripting language used extensively by Cisco to facilitate the testing and automating of various functions in the IOS. For example advanced implementations on IOS can go as far as programming a router to send you an email when its interface utilization exceeds the normally defined average. In our case we will be using very basic TCL programming to sequentially run the “ping” command.

Macro scripting on the Catalyst switches is a simple way to define templates of configuration that can be applied globally or to interfaces by issuing a single command. Examples of predefined macros include the “switchport host” command, which enables portfast, sets an interface to access mode, and disabled DTP, and the “auto qos” feature. For our implementation we will be using the macros to run pings commands sequentially.

The first step in configuring a ping script is to collect the IP addresses that will be tested in the topology. There are two simple ways to do this, either through the “show ip interface brief” command or the “show ip alias”. Both of these commands show local IP addresses allocated on the device and any addresses that are being proxied for (i.e. dns proxy or NAT). The “show ip interface brief” output can be filtered through quickly by using the “show ip interface brief | exclude unassigned” command so that only interfaces with IP addresses are listed.

Next we’ll need to copy these addresses into a text editor (i.e. Windows notepad in the CCIE lab exam), and do some basic manipulation. To do so use the column select feature of SecureCRT (the terminal emulator used in the lab exam) by holding down the ALT key and then selecting with your left mouse button. This will minimize the amount of text that we have to sort through. Once you’re done you should have a neat list of addresses in notepad that looks something like this:


192.168.255.1
192.168.255.2
192.168.255.3
192.168.255.4
192.168.255.5
192.168.255.6
192.168.255.7
192.168.255.8
192.168.255.9
192.168.255.10

Next we need to manipulate these addresses for TCL on the routers and macro scripting on the switches. For TCL we are going to define the IP addresses as an array, and then use a “for” loop to run the ping command with the array as its argument. The syntax in IOS 12.4 for this implementation is as follows:


foreach VAR {
192.168.255.1
192.168.255.2
192.168.255.3
192.168.255.4
192.168.255.5
192.168.255.6
192.168.255.7
192.168.255.8
192.168.255.9
192.168.255.10
} { puts [exec "ping $VAR"] }

Specifically we are defining the array “VAR”, which represents the IP addresses, then sending the exec command “ping” with “VAR” as the argument. Now to actually run the script in IOS we first must invoke the TCL shell. This is accomplished with the exec command “tclsh”.


Rack17R1#tclsh
+>

Now paste the script from notepad into the router and it should run the pings:


Rack17R1#tclsh
+>foreach VAR {
+>192.168.255.1
+>192.168.255.2
+>192.168.255.3
+>192.168.255.4
+>192.168.255.5
+>192.168.255.6
+>192.168.255.7
+>192.168.255.8
+>192.168.255.9
+>192.168.255.10
+>} { puts [exec "ping $VAR"] }

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 84/86/89 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 140/147/164 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 140/142/144 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/59/65 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.8, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms

Rack17R1(tcl)#

Note that in the above test we can see that the address 192.168.255.8 is unreachable. Once TCL is completed we must now make sure to exit the shell. This can be accomplished with either the “tclquit” command, or simply typing “exit” to leave the exec process. Unless TCL is exited the IOS can have some unexpected behavior, like the below example:


Rack17R1(tcl)#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack17R1(config)#route-map TCL_BREAKS_SET_COMMAND

Rack17R1(config-route-map)#set local-preference 100
100
Rack17R1(config-route-map)#end

Rack17R1(tcl)#
*Mar  1 05:45:49.906: %SYS-5-CONFIG_I: Configured from console by console
Rack17R1(tcl)#show run | section route-map
route-map TCL_BREAKS_SET_COMMAND permit 10

Rack17R1(tcl)#tclquit
Rack17R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack17R1(config)#route-map SET_FIXED_WITH_TCL_EXITED
Rack17R1(config-route-map)#set local-preference 100
Rack17R1(config-route-map)#end
Rack17R1#
*Mar  1 05:46:28.882: %SYS-5-CONFIG_I: Configured from console by console
Rack17R1#show run | section route-map
route-map TCL_BREAKS_SET_COMMAND permit 10
route-map SET_FIXED_WITH_TCL_EXITED permit 10
 set local-preference 100

The above output shows that TCL was invoked, then a global route-map named “TCL_BREAKS_SET_COMMAND” was defined. In this route-map the “set” command was issued. However with TCL still running the “set” command is first interpreted by TCL as an attempt to set an environment variable, instead of sent to the exec process itself. The result is that instead of setting local-preference for the purpose of BGP manipulation we are actually creating a variable named “local-preference” that has a value of 100. Once the “tclquit” command is issued we can see that the next route-map, “SET_FIXED_WITH_TCL_EXITED” successfully uses the set command.

Next for macro scripting on the Catalyst switches we will take the same list of IP addresses used before and prefix them with the commands “do ping”. The resulting list in notepad should look like this:


do ping 192.168.255.1
do ping 192.168.255.2
do ping 192.168.255.3
do ping 192.168.255.4
do ping 192.168.255.5
do ping 192.168.255.6
do ping 192.168.255.7
do ping 192.168.255.8
do ping 192.168.255.9
do ping 192.168.255.10

Next we’ll insert these commands as a sequence in a global macro as follows:


Rack17SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack17SW1(config)#macro name PING_SCRIPT
Enter macro commands one per line. End with the character '@'.
do ping 192.168.255.1
do ping 192.168.255.2
do ping 192.168.255.3
do ping 192.168.255.4
do ping 192.168.255.5
do ping 192.168.255.6
do ping 192.168.255.7
do ping 192.168.255.8
do ping 192.168.255.9
do ping 192.168.255.10
@
Rack17SW1(config)#

We now have a script named “PING_SCRIPT” that can be run from global configuration. To apply the script use the following syntax:


Rack17SW1(config)#macro global apply PING_SCRIPT

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 51/57/59 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 25/30/34 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 84/89/101 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 83/87/93 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 50/57/59 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 50/57/59 ms
Rack17SW1(config)#

Once you are proficient in this methodology building both the TCL and macro scripts should only take about 2 – 3 minutes in the lab, with another 5 minutes to run them. The resulting time savings versus running manual pings to all segments, and the resulting information on what is reachable and what is not can be the difference between passing and failing the CCIE lab exam.

Tags: , , , , ,

Feb
19

UPDATE: For more information on Redistribution see the video series Understanding Route Redistribution – Excerpts from CCIE R&S ATC

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.

Continue Reading

Tags: , , , , , ,

Feb
18

Brian,First off, thanks for this great website and the great effort. One question about the CCIR R&S. Is grading effected by executing show or debug commands? Many cases I configure elements and I’m pretty sure that it will work, and omit the verification stage. In other words, does the proctor/script look at monitoring commands I executed, and if not, he marks me down because of simply not monitoring even though the configuration is fully functional?Kind regards,M. Khonji

The proctors don’t monitor your progress during the day for grading purposes. I.e if you configure OSPF and don’t issue the “show ip ospf neighbor” output it’s not going to make a difference as long as your configuration is functional. Now on the other hand grading itself can be based on either the configuration or the result. By this I mean that simple feature configurations, such as IP Accounting or SNMP or RMON would most likely be graded by looking at your running configuration, as there is usually only one way to accomplish a particular goal with features such as that. However more complex configurations like BGP or redistribution may be graded not based on your configurations but based on their results. I.e if you are asked to modify the BGP bestpath selection process, the easiest way to check this is to view the “show ip bgp” output and then to send traffic through the network with traceroute and see where it actually goes. Based o n this fact I would highly recommend to try to verify as much of the results of your configurations as possible in the real lab before leaving at the end of the day.Good luck in your preparation!

Tags: , , ,

Feb
15

Quite many people don’t pay attention to the difference in handling packets on interfaces configured for NAT inside and outside. Here is an example to demonstrate how NAT “domains” interact with routing. Consider three routers connected in the following manner:

nat-inside-outside

For this scenario we have no routing configured. Let’s use static NAT to provide connectivity between R1 and R2. R2 would see R1 as a host on local connected segment with the IP address 155.1.23.1 and R1 would see R2 as a host on it’s local segment with the IP address 155.1.13.2. This goal could be achieved with the following configuration:


R3:
!
interface Serial 1/0.301 point-to-point
 ip address 155.1.13.3 255.255.255.0
 ip nat inside
 no ip route-cache
!
interface Serial 1/0.302 multipoint
 ip address 155.1.23.3 255.255.255.0
 frame-relay map ip 155.1.23.2 302
 ip nat outside
 no ip route-cache

!
! Static NAT: translations are effectively bi-directional
!
ip nat inside source static 155.1.13.1 155.1.23.1
ip nat outside source static 155.1.23.2 155.1.13.2

R2:
!
! Add a Frame-Relay mapping for the new IP (representing R1)
! so that R2 would know how to reach the address over multipoint FR interface
!
interface Serial 1/0.203 multipoint
 ip address 155.1.23.2 255.255.255.0
 frame-relay map ip 155.1.23.3 203
 frame-relay map ip 155.1.23.2 203

Let’s see how it’s working. Note that we disabled route-cache on both interfaces to intercept packets via CPU.


Rack1R3#debug ip nat detailed
IP NAT detailed debugging is on

Rack1R3#debug ip packet detail
IP packet debugging is on (detailed)

Rack1R2#ping 155.1.23.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.23.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Hmm…it fails. Look at the debugging output on R3:


Rack1R3#
!
! Packet on NAT outside (o - for outside) hits the interface
!
NAT*: o: icmp (155.1.23.2, 16) -> (155.1.23.1, 16) [84]

!
! Source and destination for the packet rewritten according to NAT rules
!
NAT*: s=155.1.23.2->155.1.13.2, d=155.1.23.1 [84]
NAT*: s=155.1.13.2, d=155.1.23.1->155.1.13.1 [84]

!
! The packet is routed after translation (with new source and destination IPs). Note that routing decision
! and the actual forwarding take place only after translation rules were triggered by NAT tables
!
P: tableid=0, s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), routed via RIB
IP: s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), g=155.1.13.1, len 100, forward
    ICMP type=8, code=0
!
! The response packet from R1 comes in - to destination 155.1.13.2 -  routed via RIB (to the same interface)
! But no NAT rules were triggered since the destination interface is the same as input interface!
!
IP: tableid=0, s=155.1.13.1 (Serial1/0.301), d=155.1.13.2 (Serial1/0.301), routed via RIB
IP: s=155.1.13.1 (Serial1/0.301), d=155.1.13.2 (Serial1/0.301), len 100, rcvd 3
    ICMP type=0, code=0

OK hold here for a second.. Now we recall that for inside NAT routing is tried first, and only then the packet is translated according to the NAT rules. This is how the NAT order of operations works on the inside. So now it’s clear: IOS first tries to route packet to 155.1.13.2 – which is the same interface as it came in.. therefore the inside->outside translation never occurs! To fix this, let’s add a static route on R3:


R3:
ip route 155.1.13.2 255.255.255.255 155.1.23.2

Verification:


Rack1R2#ping 155.1.23.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.23.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/33/52 ms

Rack1R3#
!
! Outside: translate & route
!
NAT*: o: icmp (155.1.23.2, 17) -> (155.1.23.1, 17) [89]
NAT*: s=155.1.23.2->155.1.13.2, d=155.1.23.1 [89]
NAT*: s=155.1.13.2, d=155.1.23.1->155.1.13.1 [89]

!
! Routing decision and forwarding
!
IP: tableid=0, s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), routed via RIB
IP: s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), g=155.1.13.1, len 100, forward
    ICMP type=8, code=0
!
! Inside: Routing decision - the packet is routed using our fixup static route
!
IP: tableid=0, s=155.1.13.1 (Serial1/0.301), d=155.1.13.2 (Serial1/0.302), routed via RIB

!
! NAT rule (i - for inside) is triggered by the packet
!
NAT: i: icmp (155.1.13.1, 17) -> (155.1.13.2, 17) [89]     

!
! Source and destination addresses rewritten in the "opposite" direction
!
NAT: s=155.1.13.1->155.1.23.1, d=155.1.13.2 [89]
NAT: s=155.1.23.1, d=155.1.13.2->155.1.23.2 [89]

!
! Packet is sent to R2 (with the new source and destination) - forwarding takes place
!
IP: s=155.1.23.1 (Serial1/0.301), d=155.1.23.2 (Serial1/0.302), g=155.1.23.2, len 100, forward
    ICMP type=0, code=0

Nice. So now we know the difference for sure: packets on the NAT outside are first translated and then routed. On the inside interface routing decision kicks in first and only then translation rules get applied followed by forwarding. Before we finish with that, recall new 12.3T feature called NAT Virtual Interface. With this feature we can now configure any interface as “NAT enabled” an get rid of those “inside” and “outside” domains . All NAT traffic passed through new virtual interface called NVI, in symmetric manner. Let’s reconfigure out task using this new concepts.


R3:
interface Serial 1/0.301 point-to-point
 no ip nat inside
 ip nat enable
!
interface Serial 1/0.302 multipoint
 no ip nat outside
 ip nat enable

!
!  Remove old rules
!
no ip nat inside source static 155.1.13.1 155.1.23.1
no ip nat outside source static 155.1.23.2 155.1.13.2

!
! Add "domainless" rules
!
ip nat source static 155.1.13.1 155.1.23.1
ip nat source static 155.1.23.2 155.1.13.2

no ip route 155.1.13.2 255.255.255.255 155.1.23.2

Verification:


Rack1R2#ping 155.1.23.1                 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.23.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/40/60 ms

Rack1R3#
!
! Routing decision it taken: packet classified for NAT, since destination is in NAT table
! Note that no actual forwarding occurs, just routing decision to send packet
!
IP: tableid=0, s=155.1.23.2 (Serial1/0.302), d=155.1.23.1 (Serial1/0.302), routed via RIB

!
! Packet translated according to NAT rules (note "i" for inside NAT)
!
NAT: i: icmp (155.1.23.2, 19) -> (155.1.23.1, 19) [95]
NAT: s=155.1.23.2->155.1.13.2, d=155.1.23.1 [95]
NAT: s=155.1.13.2, d=155.1.23.1->155.1.13.1 [95]

!
! Another routing decision, for translated packet - now actual forwarding occurs
!
IP: tableid=0, s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), routed via RIB
IP: s=155.1.13.2 (Serial1/0.302), d=155.1.13.1 (Serial1/0.301), g=155.1.13.1, len 100, forward
    ICMP type=8, code=0

!
! Response comes in, first routing decision - NAT table entry matched
!
IP: tableid=0, s=155.1.13.1 (Serial1/0.301), d=155.1.13.2 (Serial1/0.301), routed via RIB

!
! Packet translated ("i" - inside NAT)
!
NAT: i: icmp (155.1.13.1, 19) -> (155.1.13.2, 19) [95]
NAT: s=155.1.13.1->155.1.23.1, d=155.1.13.2 [95]
NAT: s=155.1.23.1, d=155.1.13.2->155.1.23.2 [95]

!
! Another routing decision, for post-translated packet, followed by forwarding
!
IP: tableid=0, s=155.1.23.1 (Serial1/0.301), d=155.1.23.2 (Serial1/0.302), routed via RIB
IP: s=155.1.23.1 (Serial1/0.301), d=155.1.23.2 (Serial1/0.302), g=155.1.23.2, len 100, forward
    ICMP type=0, code=0

So what’s the difference with NVI? First, we see that now NAT behaves symmetrically. Next, we see that NAT translation tables are used to take a “routing decision” to send packet to virtual interface. Packet is translated there and then another routing decision takes place, followed by packet forwarding. So the difference from the old model is that now routing decision is taken twice: before and after translation. This allows to get rid of any static routes needed by “legacy” NAT, since lookup is performed after translation.

To summarize: Domain-based NAT uses different orders of operations for inside and outside domain. NVI based NAT is symmetrical and performs routing lookup twice: first to send packet to NVI, second to route packet using the post-translated addresses.

Links:

NAT Order of Operation

Tags: , , , ,

Feb
13

Cisco IOS has a special feature called local policy routing, which permits to apply a route-map to local (router-generated) traffic. The first way we can use this feature is to re-circulate local traffic (and force it re-enter the router). Here’s an example. By default, locally-generated packets are not inspected by outgoing access-lists. This may cause issues when local traffic is not being reflected under relfexive access-list entries. Say with configuration like that:


!
! Reflect all "session-oriented" traffic
!
ip access-list extended EGRESS
 permit tcp any any reflect MIRROR
 permit icmp any any reflect MIRROR
 permit udp any any reflect MIRROR
!
! Evalute the reflected entries
!
ip access-list extended INGRESS
 evaluate MIRROR
 permit ospf any any
!
interface Serial 0/0
 ip address 54.1.1.6 255.255.255.0
 ip access-group INGRESS in
 ip access-group EGRESS out

You would not be able to telnet out of a router to destinations behind the Serial interface, even though TCP sessions are reflected in access-list. To fix the issue, we may use local-policy to force the local traffic re-enter the router and be inspected by outgoing access-list:


!
! Redirect local telnet traffic via the Loopback interface
!
ip access-list extended LOCAL_TRAFFIC
 permit tcp any any eq 23
!
route-map LOCAL_POLICY 10
 match ip address LOCAL_TRAFFIC
 set interface Loopback0
!
! Traffic sent to Loopback interface re-enters the router
!
interface Loopback0
 ip address 150.1.6.6 255.255.255.50

!
! Apply the local-policy
!
ip local policy route-map LOCAL_POLICY

With this configuration, local telnet session will re-enter the router and hit the outgoing access-list, thereby triggering a reflected entry. This same idea may be utilized to force CBAC inspection of locally-generated traffic, by since 12.3T there has been a special IOS feature to do this natively.

The other useful application of local policy routing is using it for traffic filtering. For example you may want to prohibit outgoing telnet sessions from local router to a certain destination:


ip access-list extended BLOCK_TELNET
 permit tcp any host 150.1.1.1 eq 23
!
route-map LOCAL_POLICY 10
 match ip address BLOCK_TELNET
 set interface Null 0

!
! Apply the local-policy
!
ip local policy route-map LOCAL_POLICY

The syntax is somewhat similar to the vlan access-maps used on Catalyst switches, and similarly the route-map is applied “globally”, i.e. to all router traffic, going out on any interface. Note that you may use the same idea to block incoming session, simply by reversing entries in access-list. (e.g. “permit tcp any eq 23 host 150.1.1.1″). Best of all, with PBR you may apply additional criteria to incoming traffic, e.g. match packet sizes.

The last example is the use of local PBR to apply special treatment to management/control plane traffic – e.g. use different output interfaces for out-of-band management. With local PBR you may also apply special marking for control traffic, e.g. selectively assign IP precedence values.


ip access-list extended MANAGEMENT_TRAFFIC
 permit tcp any eq 23 any
 permit tcp any eq 22 any
!
route-map LOCAL_POLICY 10
 match ip address MANAGEMENT_TRAFFIC
 set interface Serial 0/1
 set ip precedence 7
!
ip local policy route-map LOCAL_POLICY

Keep these simple features in mind, while considering options for you CCIE lab task solution.

Tags: , , ,

Feb
09

UPDATE: For more information on Redistribution see the video series Understanding Route Redistribution – Excerpts from CCIE R&S ATC

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

Redistribution_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 metric feature).

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.

Tags: , , , , , ,

Feb
06

Guys,

I ran into a task in a lab to configure an ACL to allow BGP and the book has it configured like this:

Permit tcp host 150.1.5.5 eq bgp host 150.1.4.4
Permit tcp host 150.1.5.5 host 150.1.4.4 eq bgp

Is there a reason why it is configured like that instead of ‘Permit tcp host 150.1.5.5 eq bgp host 150.1.4.4 eq bgp’ ?

The only reason I could think of was to allow source/destination traffic from tcp 179 to a different port.

Ted

Hi Ted,

Your reasoning is correct; it is because BGP uses different source and destination ports other than 179 depending on who originates the session. BGP is essentially a standard TCP based protocol, which means that it is client and server based.

When a TCP client attempts to establish a connection to a TCP server it first sends a TCP SYN packet to the server with the destination port as the well known port. This first SYN essentially is a request to open a session. If the server permits the session it will respond with a TCP SYN ACK saying that it acknowledges the request to open the session, and that it also wants to open the session. In this SYN ACK response the server uses the well known port as the source port, and a randomly negotiated destination port. The last step of the three way handshake is the client responding to the server with a TCP ACK, which acknowledges the server’s response and completes the connection establishment.

Now from the perspective of BGP specifically the TCP clients and servers are routers. When the “client” router initiates the BGP session is sends a request to the server with a destination port of 179 and a random source port X. The server then responds with a source port of 179 and a destination port of X. Therefore all client to server traffic uses destination 179, while all server to client traffic uses source 179. We can also verify this from the debug output in IOS.

In the below topology R1 and R2 are directly connected BGP peers on an Ethernet segment with configurations as follows:

R1:
interface Ethernet0/0
 ip address 10.0.0.1 255.255.255.0
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
router bgp 1
 network 1.1.1.1 mask 255.255.255.255
 neighbor 10.0.0.2 remote-as 1

R2:
interface Ethernet0/0
 ip address 10.0.0.2 255.255.255.0
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
router bgp 1
 network 2.2.2.2 mask 255.255.255.255
 neighbor 10.0.0.1 remote-as 1

From the “debug ip packet detail” output we can see the initial TCP session establishment for BGP between these neighbors as follows:

R1:
IP: tableid=0, s=10.0.0.2 (Ethernet0/0), d=10.0.0.1 (Ethernet0/0), routed via RIB
IP: s=10.0.0.2 (Ethernet0/0), d=10.0.0.1 (Ethernet0/0), len 44, rcvd 3
    TCP src=11000, dst=179, seq=3564860120, ack=0, win=16384 SYN

R2:
IP: tableid=0, s=10.0.0.1 (Ethernet0/0), d=10.0.0.2 (Ethernet0/0), routed via RIB
IP: s=10.0.0.1 (Ethernet0/0), d=10.0.0.2 (Ethernet0/0), len 44, rcvd 3
    TCP src=179, dst=11000, seq=1977460611, ack=3564860121, win=16384 ACK SYN

R1:
IP: tableid=0, s=10.0.0.2 (Ethernet0/0), d=10.0.0.1 (Ethernet0/0), routed via RIB
IP: s=10.0.0.2 (Ethernet0/0), d=10.0.0.1 (Ethernet0/0), len 40, rcvd 3
    TCP src=11000, dst=179, seq=3564860121, ack=1977460612, win=16384 ACK

In the first code snippet we can see that R1 has received a TCP packet from R2. This packet was sourced from 10.0.0.2 (R2), destined to 10.0.0.1 (R1), has a TCP source port of 11000 (the random port), a destination TCP port of 179 (the well known port), and is a SYN packet (1st step of three way handshake).

Next R2 receives the response from R1 that is a TCP SYN ACK, but in this case we can see that the port numbers are swapped. R1, the TCP server, now uses TCP port 179 as the source port, and the randomly negotiated port 11000 as the destination.

Further debugging of the BGP flow between these neighbors will show R1 using destination 179 (as the TCP client) and R2 using source 179 (as the TCP server).

The implication of this operation is that if BGP needs to be matched for some reason, i.e. to filter it out in an access-list, to match it in a QoS policy, we must account for traffic that is both going to TCP port 179 and coming from TCP port 179.

Tags: , ,

Categories

CCIE Bloggers