We have completed the upgrade of IEOC! All posts, comments and user profiles have been migrated. For security reasons, we have reset all passwords. To set a new password please Click Here. Further updates soon to follow.

10.2 WFQ, getting "Broken pipe" error when testing.

Has anyone come across a "Broken pipe" error when initiating the two HTTP flows from SW2 and SW4?

I initiated the HTTP flow from R5 and it works, it seems to be just an issue with SW2 & SW4

This is the error:


Rack1SW4#copy http://admin:cisco@155.1.146.1/c2691-advipservicesk9-mz.124-23.bin null:

Loading http://***********@155.1.146.1/c2691-advipservicesk9-mz.124-23.bin !

%Error reading http://admin:cisco@155.1.146.1/c2691-advipservicesk9-mz.124-23.bin (Broken pipe)

Rack1SW4#

Comments

  • To add, I can see where the requests are making it to R1....


    Rack1R1#sh ip http server history 

     

    HTTP server history:

    local-ipaddress:port  remote-ipaddress:port in-bytes   out-bytes  end-time

        155.1.146.1:80       155.1.108.10:47948 195        22127      22:40:58 04/13

        155.1.146.1:80       155.1.108.10:18875 195        22127      22:42:30 04/13

     

    I thinking it's something on the return path but I haven' t been able to narrow it down.

  • I faced the same error. but it was typo mistake.

    Server not found

    name of file is wrong.

    after that i am facing new problem


    S12#copy http://150.1.4.4:8080/c181x-advipservicesk9-mz.124-6.T11.bin null:

    %Error opening http://150.1.4.4:8080/c181x-advipservicesk9-mz.124-6.T11.bin (Permission denied)

    either i configure

    ip http server authentication local

    + username password localy.

    same error all time.

  • I get the same thing.  I ended up just configuring tftp server. 

     

  • Getting the same error here. But @willpower, TFTP will not give you same result. Its a UDP flow, thus non-adaptive and greedy. If you look at the Policy-map on R5, you will realize that it ends up giving pretty much same bandwidth to BOTH flows.

    Nic

  • Guys, its the low MTU on P-2-P of R4 and R5 causing problems. Exactly why, I do not yet know. Probably, the processing time on R4 goes too high.

    Anyway, with the LOW MTU, the debug ip http errors on R6/R1 gives the following -

    *Mar 17 16:44:21.707: http_tty_send_data_block send failed ret_status=2

    But with a default MTU, the flows are working fine and the METER actually shows the results.

    Hope someone finds out the exact problem, good luck to you all.

    Nic.

  • Nic,

    you're right.  thanks for pointing that out.  I didn't even think about because when i showed policy-map int s0/1, it showed a flow rate of about twice the other, basically what the lab book showed. 

     

  • I was getting the permission error and had to change the privelage level of admin to 15.

     

    username admin privelage 15 secret 0 cisco

     

    But i'm still not able to figure out the broke pipe error. Anyone else?

     

  • So I think I figured this one out. The problem apprears to be on the TCP level with checksum failure.

    #debug ip tcp transaction

    Rack1SW2#$co@155.1.146.6/c2800nm-adventerprisek9-mz.124-15.T5.bin null:
    Loading http://admin:cisco@155.1.146.6/c2800nm-adventerprisek9-mz.124-15.T5.bin
    1d06h: TCB03CC39D8 created
    1d06h: TCB03CC39D8 setting property TCP_NO_DELAY (0) 3AE1A84
    1d06h: TCB03CC39D8 setting property TCP_NONBLOCKING_WRITE (7) 3AE1ADC
    1d06h: TCB03CC39D8 setting property TCP_NONBLOCKING_READ (8) 3AE1ADC
    1d06h: TCB03CC39D8 setting property TCP_KEEPALIVE (4) 3AE1A48
    1d06h: TCB03CC39D8 setting property TCP_NODELAY_ACK (9) 3AE1ADC
    1d06h: TCP: sending SYN, seq 3233642522, ack 0
    1d06h: TCP0: Connection to 155.1.146.6:80, advertising MSS 536
    1d06h: TCP0: state was CLOSED -> SYNSENT [11017 -> 155.1.146.6(80)]
    1d06h: TCP0: state was SYNSENT -> ESTAB [11017 -> 155.1.146.6(80)]
    1d06h: TCP0: Connection to 155.1.146.6:80, received MSS 536, MSS is 536
    1d06h: TCP: checksum failure <155.1.146.6,80> <155.1.58.8,11017>
    1d06h: TCP: checksum failure <155.1.146.6,80> <155.1.58.8,11017>
    1d06h: TCP: checksum failure <155.1.146.6,80> <155.1.58.8,11017>
    1d06h: TCP: checksum failure <155.1.146.6,80> <155.1.58.8,11017>!
    %Error reading
    http://admin:cisco@155.1.146.6/c2800nm-adventerprisek9-mz.124-15.T5.bin (Broken pipe)
    Rack1SW2#
    1d06h: TCP0: state was ESTAB -> FINWAIT1 [11017 -> 155.1.146.6(80)]
    1d06h: TCP0: sending FIN
    1d06h: TCP0: state was FINWAIT1 -> FINWAIT2 [11017 -> 155.1.146.6(80)]
    Rack1SW2#
    1d06h: TCP0: bad seg from 155.1.146.6 -- Application closed: port 11017 seq 4053438994 ack 3233642719 rcvnxt 4053438994 rcvwnd 4128 len 536
    1d06h: TCP: sending RST, seq 3233642719, ack 0
    1d06h: TCP0: state was FINWAIT2 -> CLOSED [11017 -> 155.1.146.6(80)]
    1d06h: TCB 0x3CC39D8 destroyed

    As you can see the TCP handshake occurs but nothing after that so sessions is teared down. The other think I noticed is that the MSS is 536.

     

    The way I fixed it is by modifying the mss of the server in this case R1 and R6:

    ip tcp mss 100

     

    Rack1SW2#$co@155.1.146.6/c2800nm-adventerprisek9-mz.124-15.T5.bin null:
    Loading http://admin:cisco@155.1.146.6/c2800nm-adventerprisek9-mz.124-15.T5.bin
    1d06h: TCB03CBE0B8 created
    1d06h: TCB03CBE0B8 setting property TCP_NO_DELAY (0) 3AE1A84
    1d06h: TCB03CBE0B8 setting property TCP_NONBLOCKING_WRITE (7) 3AE1ADC
    1d06h: TCB03CBE0B8 setting property TCP_NONBLOCKING_READ (8) 3AE1ADC
    1d06h: TCB03CBE0B8 setting property TCP_KEEPALIVE (4) 3AE1A48
    1d06h: TCB03CBE0B8 setting property TCP_NODELAY_ACK (9) 3AE1ADC
    1d06h: TCP: sending SYN, seq 1937371456, ack 0
    1d06h: TCP0: Connection to 155.1.146.6:80, advertising MSS 536
    1d06h: TCP0: state was CLOSED -> SYNSENT [11018 -> 155.1.146.6(80)]
    1d06h: TCP0: state was SYNSENT -> ESTAB [11018 -> 155.1.146.6(80)]
    1d06h: TCP0: Connection to 155.1.146.6:80, received MSS 136, MSS is 136
    1d06h: TTY0 packets merged=0 bytes merged=0
    1d06h: TTY0 packets merged=0 bytes merged=0
    1d06h: TTY0 packets merged=0 bytes merged=0
    1d06h: TTY0 packets merged=0 bytes merged=0
    1d06h: TTY0 packets merged=0 bytes merged=0
    1d06h: TTY0 packets merged=0 bytes merged=0
    1d06h: TTY0 packets merged=0 bytes merged=0
    1d06h: TTY0 packets merged=0 bytes merged=0
    1d06h: TTY0 packets merged=0 bytes merged=0
    1d06h: TTY0 packets merged=0 bytes merged=0

    As you can see not tcp checksum errors and copying work correctly.

     

    As a summary these are the changes I had to make to this lab to test it correctly, hopefully it can make it to the next revision of this lab.

     

    R1 and R6

    username admin privelage 15 secret 0 cisco

    ip http authentication local

    ip tcp mss 100

  • ip tcp mss 100 does not solve the problems.

    I have this command applied both on my R1 and R6, but I cannot download simultaneously from both of them. (one download gets broken pipe).

    When I download only from one router, everything is okay.

     

  • Hi all,

    Just reviewing QoS section. Any progress on this issue?

     

  • Aloha,

    I have just started with my journey.

    And still have this issue.

    The problem only exist with the low IP MTU on the serial links, as Nic also pointed out.

     

    Any suggestions for the cause?

    Cheers

    Marcel

  • Wow,

    Never thought I would see this topic revive again, back from the dead.

    Something I did not know back then and do know now, try the adjust-mss but not on the originating routers.

    Try it on the interface with the artificially low MTU.

    What this will do is "massage" the MSS field in the TCP three-way handshake to a value that will result in IP packets not exceeding the IP MTU and therefore not needing fragmentation.

    I do not remember the exact scenario and do not have the workbook in front of me but this article should help you calculate the exact MSS you need to set.

    http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

    Although for GRE, it should help resolve the situation here as well.

    Let me know how the experimentation goes.

    Good luck with your studies.

    Nic

  • I have removed ip mtu 156 on the p-2-p interfaces on both R4 and R5 and I am still unable to run both file transfers at the same time.

     

    newagequanta, did you remeber what you did to resolve the issue?

  • HI Nic,

    many thanks for answering this thread after all the time.

    :-)

    In the newest workbook version is in the solution 



    ip tcp mss 100
    preconfigured on the "http server" router R1 and R6.
    Anyway, this does not solve the issue.
    Unfortunately your suggestion to use:
    ip tcp adjust-mss
    also does not do the job.
    Minimum values is 500 bytes, but through the MTU size condigured only to 156 byte, this does not help.
    
    
    Cheers
    Marcel



  • Change the "ip tcp mss" to something larger, for example --> 1000:

    ip tcp mss 1000

     


    This worked for me, nothing else did. I also removed the configure mtu of 156.

     

    BR,

    Jussi

  • Chaning the mss to 1000 and removing the mtu didn't work for me.

    HTTP download worked after the change but the traffic load was split even.

  • Chaning the mss to 10000 (MAX value allowed) and removing the mtu seemed to have resolved the issue

    Two traffics started to flow simultaneously, but not in 2:1 ratio 

     

Sign In or Register to comment.