Sunday, August 11, 2013

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

Saturday, August 10, 2013

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.


Thursday, August 8, 2013

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





Sunday, August 4, 2013

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.











Friday, August 2, 2013

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.