Why do we need to go through multiple cycles in block cipher According to Computer Networking: a top down approach, Chapter 8 (6th edition), block ciphers involves breaking the input message into blocks of size k, where generally k = 64. However since k = 64 implies that we need to create a table of input size 2k or 264 in our case, therefore we simulate randomly permuted tables. To simulate, we use the following process. The function first breaks a 64-bit block into 8 chunks, with each chunk consisting of 8 bits. Each 8-bit chunk is processed by an 8-bit to 8-bit table, which is of manageable size. For example, the first chunk is processed by the table denoted by T 1 . Next, the 8 output chunks are reassembled into a 64-bit block. The positions of the 64 bits in the block are then scrambled (permuted) to produce a 64-bit output. This output is fed back to the 64-bit input, where another cycle begins. After n such cycles, the function provides a 64-bit block of ciphertext. 

Here is the question: Why do we need to process the text through n such cycles? The book states that 


  The purpose of the rounds is to make each input bit affect most (if not all) of the final output bits. (If only one round were used, a given input bit would effect only 8 of the 64 output bits.)


The key for this block cipher algorithm would be the eight
permutation tables (assuming the scramble function is publicly known).

*Personal Comment - 
However, if the input text has gone through even a single cycle still all the inputs would have been affected since each block went through a mapping based on the corresponding table Tj table. Hence we shouldn't be required to cycle it through n cycles.
First of all, I wouldn't rely on that book for information about modern cryptography.  It might be a fine reference for networking in general, however based on the example they gave, it would appear that they really don't know their crypto.  The example cipher they gave feels like something from the '90s.

Modern block ciphers use $k=128$; the issue with $k=32$ is that you tend to leak information about the plaintext after encrypting a few gigabytes with the same key; with modern networks, you can hit a few gigabytes easily.  In addition, key dependent sboxes have gone out of fashion; they are a bit expensive in hardware, they tend to leak timing data in software (due to caching), and the sboxes are sometimes not particularly strong against differential or linear cryptanalysis.

As for your question:


  Why do we need to process the text through n such cycles?


Consider the case where $n=1$, and you have two different plaintexts that differ in a single bit.  Then, if you look at the two parallel encryptions, the inputs for seven of the sboxes are precisely the same (because they only depend on inputs that have not changed), and so only one sbox (say, $T_0$) has its output changed.  That sbox has 8 output bits, and so when you go through the 64-bit scrambler, then you have 56 output bits that would always be the same, and 8 that are potentially changed.  This is far short of 'any input bit can potentially affect any output bit'.

There are more sophisticated things we can do for larger $n$; this simple reasoning shows that the $n=1$ case just doesn't cut it...