Policy-Based Routing

In certain cases, the best path isn't always the "best path". Mainly best path is determined by the routing protocol depending on metric calculations which may be simple like in OSPF and RIP or complex in case of EIGRP. The key here is that the routing protocols affects all types of traffic since it all run under the same rule of the IGP best path.

Sometimes we want to change the default behavior for security reasons or “actual” best path reasons. This can be achieved by policy-based routing or PBR.

There are two types of PBR.

1.   Transient traffic PBR: which is the traffic passing by a router along it path

2.   Local traffic PBR: which is traffic sourced from the router itself.

Transient traffic PBR

To understand how transient traffic is processed in both incoming and outgoing directions, Let’s take a look Cisco routers process packets.

Incoming Packet	Outgoing Packet
. If IPSec then check input access list	. If IPSec then check input access list
. decryption - for CET (Cisco Encryption Technology) or IPSec	. decryption - for CET or IPSec
. check input access list	. check input access list
. check input rate limits	. check input rate limits
. input accounting	. input accounting
. redirect to web cache	. redirect to web cache
. policy routing	. NAT outside to inside (globalto local translation)
. routing	. policy routing
. NAT inside to outside (local to global translation)	. routing
. crypto (check map and mark for encryption)	. crypto (check map and mark for encryption)
. check output access list	. check output access list
. inspect (Context-based Access Control (CBAC))	. inspect CBAC
. TCP intercept	. TCP intercept
. encryption	. encryption
. Queueing	. Queueing

From the table above, PBR matches before routing, thus it skips the normal routing.

From the topology shown below, let’s see a traceroute from R4 loopback 4.4.4.4 to R1 loopback 1.1.1.1 nothing that all routers below are using OSPF as their routing protocols without any special modifications.

R4#traceroute 1.1.1.1 source 4.4.4.4 numeric

Type escape sequence to abort.

Tracing the route to 1.1.1.1

  1 10.3.4.3 24 msec 28 msec 16 msec

  2 10.2.3.2 52 msec 44 msec 16 msec

  3 10.1.2.1 72 msec *  52 msec

The trace shows that for R4 to get to R1, R3 as a transient router will choose R2 to forward the packets to since the link cost to R1 is 64 and to R2 is 1.

Now let’s enforce transient traffic with source ip 4.4.4.4 and destination ip 1.1.1.1 to go to R1 directely instead of R2.

First let’s create a named extended access-list to match our traffic.

R3(config)#ip access-list extended PBR

R3(config-ext-nacl)#permit ip host 4.4.4.4 host 1.1.1.1

Now let’s create a route-map to match the access-list traffic and set “next-hop or exit interface” to R1 directly.

This is how you set it for next-hop IP

route-map PBR permit 10

 match ip address PBR

 set ip next-hop 10.1.3.1

And this is for exit interface

route-map PBR permit 10

 match ip address PBR

 set interface Serial0/0

Now let’s apply the route-map under the incoming interface in R3, in our case its interface F1/0

R3(config)#int f1/0

R3(config-if)#ip policy route-map PBR

As a final set, let’s check interface F1/0

R3#show ip int f1/0

FastEthernet1/0 is up, line protocol is up

  Internet address is 10.3.4.3/24

  Broadcast address is 255.255.255.255

  Address determined by setup command

  MTU is 1500 bytes

  Helper address is not set

  Directed broadcast forwarding is disabled

  Multicast reserved groups joined: 224.0.0.5 224.0.0.6

  Outgoing access list is not set

  Inbound  access list is not set

  Proxy ARP is enabled

  Local Proxy ARP is disabled

  Security level is default

  Split horizon is enabled

  ICMP redirects are always sent

  ICMP unreachables are always sent

  ICMP mask replies are never sent

  IP fast switching is enabled

  IP fast switching on the same interface is disabled

  IP Flow switching is disabled

  IP CEF switching is enabled

  IP CEF Feature Fast switching turbo vector

  IP multicast fast switching is enabled

  IP multicast distributed fast switching is disabled

  IP route-cache flags are Fast, CEF

  Router Discovery is disabled

  IP output packet accounting is disabled

  IP access violation accounting is disabled

  TCP/IP header compression is disabled

  RTP/IP header compression is disabled

  Policy routing is enabled, using route map PBR

  Network address translation is disabled

  BGP Policy Mapping is disabled

  WCCP Redirect outbound is disabled

  WCCP Redirect inbound is disabled

  WCCP Redirect exclude is disabled

R3#show ip policy

Interface      Route map

Fa1/0          PBR

Now for the final test, let’s ping again from R4 loopback to R1 loopback

R4#traceroute 1.1.1.1 source 4.4.4.4 numeric

Type escape sequence to abort.

Tracing the route to 1.1.1.1

  1 10.3.4.3 24 msec 28 msec 16 msec

  2 10.1.3.1 48 msec *  72 msec

The traffic sourced from 4.4.4.4 and destined to 1.1.1.1 is redirected to the least preferred path which is Serial0/0 on R3.

Now let’s try to ping from another source, R4’s interface F0/0

R4#traceroute 1.1.1.1 source 10.3.4.4

Type escape sequence to abort.

Tracing the route to 1.1.1.1

  1 10.3.4.3 32 msec 24 msec 16 msec

  2 10.2.3.2 48 msec 40 msec 20 msec

  3 10.1.2.1 68 msec

Since the source ip 10.3.4.4 isn’t matched in the access-list PBR, it will take the normal routing path R3-R2-R1

A valid question might arise at this point, what is the difference between exit interface and next-hop? In the network world there are various devices that do many functions other than routing and switching. Deep Packet Inspectors or “DPIs” as an example doesn’t necessarily need IPs for transient traffic to be sniffed or inspected. So when you need to redirect IP traffic to devices like DPIs there is no next-hop IPs to forward traffic to, this is where you set an exit interface instead of next-hop. Another important note is that then the interface goes down, all matched traffic will be dropped in case of setting exit interface.

Local traffic PBR

Local traffic is the traffic generated by the router. As an example, Telnet, SSH, ICMP etc.

Since this is the sole difference between it and transient traffic PBR, we don’t need to elaborate too much about it. Let’s go directly for configuration.

Let’s say we want to telnet from R3 to R1 using the serial interface. The steps are exactly the same as we did earlier. What only matters is where we apply the route-map in our case now.

R3(config)#ip access-list extended PBR-LOCAL

R3(config-ext-nacl)#permit tcp any host 1.1.1.1 eq telnet

R3(config)#route-map PBR-LOCAL permit 10

R3(config-route-map)#match ip address PBR-LOCAL

R3(config-route-map)#set ip next-hop 10.1.3.1

R3(config)#ip local policy route-map PBR-LOCAL

To verify our configuration

R3#show ip policy

Interface      Route map

local          PBR-LOCAL

R3#show ip local policy

Local policy routing is enabled, using route map PBR-LOCAL

route-map PBR-LOCAL, permit, sequence 10

  Match clauses:

    ip address (access-lists): PBR-LOCAL

  Set clauses:

    ip next-hop 10.1.3.1

  Policy routing matches: 160 packets, 10240 bytes

you can also check the Conditional Policy-Based routing Tutorial

BGP load-sharing across different service providers with multipath-relax

In service provider world, a BGP router might be connected to many other providers in different autonomous-systems. BGP by default doesn’t load-share traffic to the same prefix through different neighboring autonomous systems, the BGP route-selection algorithm will ultimately choose one autonomous system to forward traffic to. The target from this post is to make BGP dual-home through different autonomous system.

 Let’s check Cisco’s BGP implementation when it comes to choosing the best route to a destination prefix.

1.       Exclude routes with inaccessible next-hops

2.       Prefer the path with the highest WEIGHT.

3.       Prefer the path with the highest LOCAL_PREF.

4.     Prefer the path that was locally originated via a network or aggregate BGP sub-command or through redistribution from an IGP.

5.       Prefer the path with the shortest AS_PATH.

6.       Prefer the path with the lowest origin type.

7.       Prefer the path with the lowest multi-exit discriminator (MED).

8.       Prefer eBGP over iBGP paths.

9.       Prefer the path with the lowest IGP metric to the BGP next hop.

10.   Determine if multiple paths require installation in the routing table for BGP Multipath.

11.    When both paths are external, prefer the path that was received first (the oldest one).

12.    Prefer the route that comes from the BGP router with the lowest router ID.

13.    If the originator or router ID is the same for multiple paths, prefer the path with the minimum cluster list length.

14.    Prefer the path that comes from the lowest neighbor address.

Now to complete the scene here, I need to mention one more thing. BGP by default also doesn’t load-share traffic on multiple links if it is multi-homed. To enable using different connections, we have to use BGP sub-command maximum-paths, which will enable load-sharing to neighboring autonomous-system.

From the topology shown, the tie-breaker for R1 to install the prefix 200.0.0.1/24 was either step 12 or 13, preferring R2 to forward traffic destined to 200.0.0.1

 Let’s see how it looks on R1

R1#show run | s router bgp

router bgp 100

 no synchronization

 bgp log-neighbor-changes

 neighbor 2.2.2.2 remote-as 200

 neighbor 2.2.2.2 ebgp-multihop 255

 neighbor 2.2.2.2 update-source Loopback0

 neighbor 3.3.3.3 remote-as 300

 neighbor 3.3.3.3 ebgp-multihop 255

 neighbor 3.3.3.3 update-source Loopback0

 no auto-summary

R1#show ip route

B     200.0.0.0/24 [20/0] via 2.2.2.2, 00:00:51

R1#show ip bgp 200.0.0.0

BGP routing table entry for 200.0.0.0/24, version 13

Paths: (2 available, best #2, table default)

  Advertised to update-groups:

     5

  300 400

    3.3.3.3 (metric 2) from 3.3.3.3 (3.3.3.3)

      Origin IGP, localpref 100, valid, external

  200 400

    2.2.2.2 (metric 2) from 2.2.2.2 (2.2.2.2)

      Origin IGP, localpref 100, valid, external, best

It seems that BGP chose the path through R2 as the best path. Now let’s change that behavior by issuing two commands that works in conjunction in order to achieve our goal to multi-home R1 to AS200 and AS400.

The first command is a hidden command, bgp bestpath as-path multipath-relax. The command simply tells the router to ignore the fact that the prefix is received from different autonomous systems, and to update the router table with the maximum number of hops configured by the second command maximum-paths

router bgp 100

 no synchronization

 bgp log-neighbor-changes

 bgp bestpath as-path multipath-relax

 neighbor 2.2.2.2 remote-as 200

 neighbor 2.2.2.2 ebgp-multihop 255

 neighbor 2.2.2.2 update-source Loopback0

 neighbor 3.3.3.3 remote-as 300

 neighbor 3.3.3.3 ebgp-multihop 255

 neighbor 3.3.3.3 update-source Loopback0

 maximum-paths 2

 no auto-summary

Just remember to clear or soft clear the sessions so that it takes effect

R1#show ip bgp 200.0.0.0

BGP routing table entry for 200.0.0.0/24, version 2

Paths: (2 available, best #1, table default)

Multipath: eBGP

  Advertised to update-groups:

     6

  200 400

    2.2.2.2 (metric 2) from 2.2.2.2 (2.2.2.2)

      Origin IGP, localpref 100, valid, external, multipath, best

  300 400

    3.3.3.3 (metric 2) from 3.3.3.3 (3.3.3.3)

      Origin IGP, localpref 100, valid, external, multipath

Even though BGP still sees R2 as the best exit, the routing table shows that prefix 200.0.0.0/24 has two next-hops

R1#show ip route 200.0.0.0

Routing entry for 200.0.0.0/24

  Known via "bgp 100", distance 20, metric 0

  Tag 200, type external

  Last update from 3.3.3.3 00:05:08 ago

  Routing Descriptor Blocks:

    3.3.3.3, from 3.3.3.3, 00:05:08 ago

      Route metric is 0, traffic share count is 1

      AS Hops 2

      Route tag 200

      MPLS label: none

  * 2.2.2.2, from 2.2.2.2, 00:05:08 ago

      Route metric is 0, traffic share count is 1

      AS Hops 2

      Route tag 200

      MPLS label: none

Target achieved!

Now let’s talk a little about service providers here. Just because you can load-share traffic across different service providers. Different providers have different equipment, latencies and different upstream providers. You may find the least latency and jitter on a certain provider apart from others, which will be a great choice to forward real-time traffic. The design is totally case specific, just make sure you get the right pieces together before going for it.

Understanding and configuring SNMPv3

SNMPv3 was introduced to increase security over the previous version SNMPv2c which used clear text communities to authorize SNMP operations by introducing a new security model.

The security model consists of two mains parameters,

1. Authentication (Auth):Which makes sure the proper user is using the service and it is hashed with either MD5 or SHA1.
2. Privacy (Priv): Which encrypts the data between the host and the server and it utilizes DES, 3DES or AES as an encryption methods.

Both Auth and Priv can be combined to form the security model that SNMPv3 uses to operate which can be illustrated in those three methods:

1. NOAuthPriv: No authentication and No Privacy
2. AuthNoPriv: Authentication and No Privacy
3. AuthPriv: Authentication and Privacy

The Structure of SNMPv3 consists of Groups and Users attached to those groups

• SNMP Groups: they contain access control policies to which users with certain privileges. these privileges mainly are the SNMP view they are going to either read or read/write to.
• SNMP Users: The users are assigned with a group, along with the security models they will be using ( Auth and Priv)
• SNMP Hosts: SNMP hosts are servers that recieves pushed SNMP notifications and traps. Since notifications and traps are pushed to the server, each server can be associated with only one user.

Note: SNMP uses either pull or push communication with the server. Pull is when the server requests to read or write something to the router or switch. Push is when the router or switch sends trap or notification to the server. Both are not dependent on each other, you can configure one or both of them

Now let's start configuring SNMPv3

First you have to define a view, which is the part or the MIB tree you want use, in our exmple here we will use two views, ISO view for for read only and we will call it READ and SYSTEM view for read/write and we will call it WRITE

snmp-server view READ iso includedsnmp-server view WRITE system included

Now we need to configure the SNMP group called MANAGMENT that uses both the READ and WRITE views for its associated users

snmp-server group MANAGMENT v3 priv read READ write WRITE

Now let's confirm that with show snmp group

 R1#show snmp group
groupname: ILMI                             security model:v1
readview : *ilmi                            writeview: *ilmi                        
notifyview: <no notifyview specified>    
row status: active
groupname: ILMI                             security model:v2c
readview : *ilmi                            writeview: *ilmi                        
notifyview: <no notifyview specified>    
row status: active
groupname: READGROUP                        security model:v3 priv
readview : READ                             writeview: WRITE                        
notifyview: <no notifyview specified>    
row status: active

Lets associate two users to the MANAGMENT group. READUSER and WRITEUSER

snmp-server user READUSER MANAGMENT v3 auth sha READuserAUTHENTICATIONpassword priv aes 128 READuserPRIVACYpassword

snmp-server user WRITEUSER MANAGMENT v3 auth sha WRITEuserAUTHENTICATIONpassword priv aes 128 WRITEuserPRIVACYpassword 

One thing you'll notice that when you're showing the running-configuration, the user's line will not be shown, in order to see what SNMPv3 users configured you'll have to use the command show snmp user.

R1#show snmp user 

User name: READUSER
Engine ID: 800000090300C2000F940000
storage-type: nonvolatile        active
Authentication Protocol: SHA
Privacy Protocol: AES128
Group-name: MANAGMENT

User name: WRITEUSER
Engine ID: 800000090300C2000F940000
storage-type: nonvolatile        active
Authentication Protocol: SHA
Privacy Protocol: AES128
Group-name: MANAGMENT

That looks promising, we have now configured SNMPv3 and NMS servers can pull SNMP info from the router or switch. How about configuring the router to push traps incase of a BGP event using SNMPv3, we will use user READUSER that was configured previously for that task

snmp-server host 200.0.0.1 version 3 priv READUSER bgp

let's verify that

R1#show snmp host

 Notification host: 200.0.0.1    udp-port: 162   type: trapuser: READUSER  security model: v3 priv

Running VirtualBox in GNS3

This is a video tutorial will show you how to run a VirtualBox Virtual Machine into GNS3

BGP peering over default routes

One interesting thing is that BGP can't peer over default route as RFC 4271 implies. First, let's consider this simple topology

R1#sh run | s router bgp

router bgp 1

 no synchronization

 bgp log-neighbor-changes

 neighbor 2.2.2.2 remote-as 1

 neighbor 2.2.2.2 ebgp-multihop 2

 neighbor 2.2.2.2 update-source Loopback0

 no auto-summary

R1#show ip route

....

Gateway of last resort is 10.1.2.2 to network 0.0.0.0

     1.0.0.0/32 is subnetted, 1 subnets

C       1.1.1.1 is directly connected, Loopback0

     10.0.0.0/24 is subnetted, 1 subnets

C       10.1.2.0 is directly connected, FastEthernet0/0

S*   0.0.0.0/0 [1/0] via 10.1.2.2

 R2#show run | s router bgp

router bgp 2

 no synchronization

 bgp log-neighbor-changes

 neighbor 1.1.1.1 remote-as 1

 neighbor 1.1.1.1 ebgp-multihop 2

 neighbor 1.1.1.1 update-source Loopback0

 no auto-summary

R2#show ip route

Gateway of last resort is 10.1.2.1 to network 0.0.0.0

     2.0.0.0/32 is subnetted, 1 subnets

C       2.2.2.2 is directly connected, Loopback0

     10.0.0.0/24 is subnetted, 1 subnets

C       10.1.2.0 is directly connected, FastEthernet0/0

S*   0.0.0.0/0 [1/0] via 10.1.2.1

The configuration above is to establish a BGP session between R1 and R2  using their Loopback interfaces.

R1#ping 2.2.2.2 source lo0 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/28/52 ms

There is reachability between  R1 and R2 loopbacks, but the BGP sessions won't come up.

R1#show ip bgp neighborsBGP neighbor is 2.2.2.2,  remote AS 1, internal link  BGP version 4, remote router ID 0.0.0.0  BGP state = Active

~~output omitted for brevity~~

   Connections established 0; dropped 0  Last reset never  External BGP neighbor may be up to 2 hops away.  No active TCP connection

Both R1 and R2 are in active state and no TCP session is established even though.

The Rule is simple according to RFC 4271. BGP will only try to Actively initial a TCP session with it's neighbor if it has a specific route to the neighbor.

For BGP peers to for neighbors, one must Actively initiate a session ( the one with the Higher Router-ID ) and the other will be passive. It is negotiated in the BGP Open Message

To test that, we can manually set R1 to try to actively initiate a TCP session with R2 and set R2 be passive. Adding to that, R2 will have a more specific route to R1 loopback address, which is is not supposed to work since R2 is the passive neighbor.

R1(config)#router bgp 1 

R1(config-router)#neighbor 2.2.2.2 transport connection-mode active  

R2(config)#router bgp 2 

R2(config-router)# neighbor 1.1.1.1 transport connection-mode passive 

R2(config)#ip route 1.1.1.1 255.255.255.255 10.1.2.1 

A minute later, the peers are still in active state

R1#show ip bgp neighbors
BGP neighbor is 2.2.2.2,  remote AS 2, external link
  BGP version 4, remote router ID 0.0.0.0
  BGP state = Active  

  ~ommited output~  

  Connections established 0; dropped 0
  Last reset never
  External BGP neighbor may be up to 2 hops away.
  TCP session must be opened actively
  No active TCP connection 

R2#show ip bgp neighbors
BGP neighbor is 1.1.1.1,  remote AS 1, external link
  BGP version 4, remote router ID 0.0.0.0
  BGP state = Active 

  ~ommited output~ 

  Connections established 0; dropped 0
  Last reset never
  External BGP neighbor may be up to 2 hops away.
  TCP session must be opened passively
  No active TCP connection 

Now let's flip it. We will remove the static route from R2 and i will add one on R1 pointing to R2 loopback

R2(config)#no ip route 1.1.1.1 255.255.255.255 10.1.2.1
 R1(config)#ip route 2.2.2.2 255.255.255.255 10.1.2.2
R1(config)#
*Mar  2 08:09:12.324: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up 

The session is now UP between R1 and R2.

So, here's are the rules

• For the BGP peer who actively tries to initiate a session with another peer, it must have a specific route
• For the passive peer, it will not matter if the session is over a default-route or a specific route. Both will work
• Once the peering is established, it will not be be affected by the removal of the specific route. unless you cleared the session manually or they lose communication with each other, then the Active BGP peer will need a specific route again.

Simple Traffic Generation

Through the day, you might want to generate traffic to test some QoS or IP SLA configuration before deploying it to your live network. Traffic Generators are expensive ( Like really expensive ) and rarely seen at home setups. There are other ways to generate traffic in you GNS3 labs like using 2 QEMU Virtual machines and route them to each other, but that's a hassle to do every time you create a lab and it needs a monster PC.

a simple way to generate a decent amount of traffic using a Cisco router or switch is to enable the tcp-small-servers which uses port 19 to generate some downstream telnet charachters patterns to the client. Actually this can become very hands when you need to match a small amount of traffic. here's how to do it

Consider R1 is directly connected to R2

we'll configure R1 as the server

R1(config)#service tcp-small-servers

now let's telnet from R2

you can use any of the two commands below, they're both the same

R2#telnet 10.1.2.1 chargen
or 
R2#telnet 10.1.2.2 19

Trying 10.1.2.1, 19 ... Open !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefg!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefgh"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghi#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghij$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijk%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijkl&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklm'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmn()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmno)*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnop*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopq+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrst./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstu/0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuv0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvw123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwx23456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxy3456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz 

Now let's see the amount of traffic generated with Chargen, just make sure you set the load-interval to 30 sec under the interface and give it sometime to calculate the maximum bandwidth.

R1#show interfaces f0/0 | i sec
MTU 10000 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
Keepalive set (10 sec)
30 second input rate 0 bits/sec, 1 packets/sec
30 second output rate 78000 bits/sec, 70 packets/sec 

The traffic will keep going on forever, also, make sure you know how to exit using the escape sequence which is CRTL+SHIFT+6 then X , thereafter you type disconnect to disconnect from the server back to the client

Another way to generate more traffic is to use the extended ping option, What's good about this method is that it can generate traffic up to 7 Megs ( my personal experience ), but only ICMP traffic. Of course if you want to use it for QoS to test class-maps to match certain traffic and the behavior of the queues, you can always use Precedence or DSCP instead of the traffic type just to monitor your queues.

Simply, to generate large amounts of traffic from a ping command, all you need is to increase the size of the packet and make sure you increase Layer 2 and Layer 3 MTU so that the processor won't be busy fragmenting and defragmenting the packets, which will result in faster forwarding of packets that in my case might reach 7 Megs on a Cisco 2800 router. on higher end platforms, i'm sure you can get more than that since it has faster processors.

R2#ping 10.1.2.1 repeat 1000000 size 10000
Type escape sequence to abort.
Sending 1000000, 10000-byte ICMP Echos to 10.1.2.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

R1#show interfaces f0/0 | i sec
  MTU 10000 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
  Keepalive set (10 sec)
  30 second input rate 5538000 bits/sec, 428 packets/sec
  30 second output rate 5539000 bits/sec, 431 packets/sec

as you can see, after about half a mintue, the sessions built up to reach around 5 Megs which can be very handy if you need to stress test a serial connection, monitor QoS behaviout on small links or even congest it to trigger some SNMP or SLAs

Same technique  can be achieved in Juniper 

ping 10.1.2.1 rapid count 100000 size 10000 

One final trick that can generate even more traffic is to set timeout to zero, but the traffic will be one direction only since the processor will not wait for the ICMP packet to return ( reply)

R2#ping 10.1.2.1 repeat 1000000 size 10000 timeout 0
Type escape sequence to abort.
Sending 1000000, 10000-byte ICMP Echos to 10.1.2.1, timeout is 2 seconds:
......................................................................
......................................................................
......................................................................

......................................................................

R1#show interfaces f0/0 | i sec
  MTU 10000 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
  Keepalive set (10 sec)
  30 second input rate 11076000 bits/sec, 942 packets/sec
  30 second output rate 12431000 bits/sec, 970 packets/sec

Now that's around 12 Mb of traffic, pretty neat huh!


Note: It is NOT RECOMMENDED to enable tcp-small-servers on a production router or switch, an attacker can easily use it as a vulnerability to attack and take down the box.