Packet structure while routing

Discussion in 'Cisco' started by DanS, Nov 20, 2004.

  1. DanS

    DanS Guest

    Hi there,

    I'm sure this is not the right place, but someone may be able to point me
    to the info I'm looking for.

    Quick background......I work for an OEM narrow-band wireless equipment
    company. Our products are used for many different types of low-thruput
    application's, and almost all are serial based.

    So.....in an effort to make some of our devices ethernet/IP compatible, I
    have sourced this super cool part from Lantronix, called the X-Port.
    Basically, it's an RJ-45 ethernet jack that does ethernet to serial
    conversion. It has it's own web server, telnet server, OS, and user
    program area built right into the jack.

    In it's stock form, it can really only be used as an endpoint. Once the
    built-in TCP/IP receives a packet destined for it, it then dumps it's
    payload-only data out the serial side. We had commisioned someone to
    write custom code for it that does bridging. It will listen for LAN
    packet's, take the entire packet, including header info and such, and
    send it out the serial side. When the data is received on the serial side
    of another X-Port, after going thru a wireless link, it will then re-
    assemble the data, make it into a full ethernet packet again, and the
    transmit it out on to the LAN. Bridging, that's it.

    I would like to take the bridging code and make it into a basic router.
    I've been in networking for a while, but this will be my first attempt at
    raw packet construction.

    In basic TCP/IP, if a packet is NOT destined for a host on the local
    subnet, it will then send the packet to the default gateway. Here is my
    question, when the host's deems the packet to need routing, what exactly
    does it do to with the packet when it is sent to the router ?

    Does it encapsulate it in a 'routing' packet (for lack of a better term),
    then send it to the router ? When the router receives it, does it strip
    the 'routing' packet info, examine it, and then transmit it out onto the
    LAN ? If the router has to send it to another gateway, does it then re-
    encapsulate it in another 'routing' packet ?

    Sorry for all the question's. I did search for this info first with no
    luck.

    Thanks in advance,

    DanS
     
    DanS, Nov 20, 2004
    #1
    1. Advertisements

  2. :In basic TCP/IP, if a packet is NOT destined for a host on the local
    :subnet, it will then send the packet to the default gateway. Here is my
    :question, when the host's deems the packet to need routing, what exactly
    :does it do to with the packet when it is sent to the router ?

    :Does it encapsulate it in a 'routing' packet (for lack of a better term),
    :then send it to the router ?

    No.

    :When the router receives it, does it strip
    :the 'routing' packet info, examine it, and then transmit it out onto the
    :LAN ?

    Not applicable because no such encapsulation is occuring.

    :If the router has to send it to another gateway, does it then re-
    :encapsulate it in another 'routing' packet ?

    No.

    When a device (host or router) determines that a packet is not destined
    locally, it looks through it's routing tables to find the IP of the
    next hop device. The next-hop IP that it finds from this lookup should
    be one that the first device does NOT have to be route to (e.g., the
    next hop IP is in an IP address range served by one of the interfaces
    of the first device.)

    The sending device then looks in its ARP tables for that next-hop IP to
    see if it knows the MAC address of the next-hop IP: there might be
    a static entry for it in the table, or it might recently have looked
    it up and still remember what the MAC was. If the sending device does
    not know the next-hop IP's MAC address, then the sending device sends
    out a broadcast ARP packet with the destination IP filled in; all
    devices that receive that ARP packet look into the packet to see if their
    IP is there, and the one whose IP it is sends back an ARP reply
    containing the MAC address. If the sending device did indeed have to
    ARP the IP to locate the MAC address, then the sending device could
    buffer the original packet until it gets a reply, or the sending device
    could instead drop the original packet: if the protocol was one
    that offers reliable transportation (such as TCP) then the original
    sender will retransmit the packet, and if the protocol protocol was
    not one that offers reliable transportation (such as UDP), then the
    router is just exercising the unreliability part of the transport ;-)

    So now we're in the state where the sending device knows the next-hop
    IP and the MAC address of that next hop. It then takes the packet that
    it was working with, and rewrites the destination MAC to be the MAC
    of the next hop, and rewrites the source MAC to be it's own MAC address.
    It fixes up the checksums on the packet, and dispatches the packet out
    the appropriate interface. It does NOT re-write the destination IP!

    Now, when you are working with TCP/IP all the time, it's easy to get
    into the habit of thinking that devices pay attention to packets that
    have their IP address as the destination, but that's really not how
    ethernet works. Instead, devices pay attention only to packets which
    contain their MAC address as the destination MAC, or else contain
    one of the special broadcast or multicast MAC addresses. Thus, the
    next-hop device will receive the packet not based upon the IP address
    (which might be somewhere on the other side of the world), but based
    upon the fact that the sender found the specific MAC address to send
    to on the local segment at the level -below- IP addresses. Therefore
    when the next-hop device receives the packet, the destination IP
    in the packet will still be the ultimate destination IP, not the IP
    of the router.

    The next-hop device then goes through the whole routing table lookup
    sequence, finding the next hop IP to send the packet to, finding the
    MAC address of that next hop IP, rewriting the source and destination
    MACs, fixing the checksum, and sending on to the next hop.

    It all works through a chain of routing devices, each one of which
    might not know how to directly reach the destination, but knows
    which device that it can talk to directly that it can send the packet
    to in order to get the packet further towards it's IP destination.


    The reason the source MAC is re-written as well as the destination
    MAC is so that the next-hop device knows how to directly send back
    replies [such as ICMP Unreachable] without having to go through
    the routing table to figure out how to reply.

    Further to this: anytime a device needs to reply to a packet for any
    reason (e.g., it might be part of a TCP stream that is carrying FTP
    traffic and it needs to respond with an ACK), then the device creating
    the reply can in theory just blindly copy out the source IP and source
    MAC from the packet it is replying to, put those in the destination IP
    and destination MAC fields, copy out the destination IP and destination
    MAC from the packet it is replying to, put those in the source IP and
    source MAC fields, add the data it wants, and then just dispatch the
    reply packet *without going through the routing procedure* (as long as
    it knows which interface to use.)

    Taking this one step further: if you have communication over a local
    loop with no routing involved, then the -only- time any IP needs to
    be paid attention to is for the very first routing decision that
    located the MAC of the destination machine. After that, in theory
    the entire rest of the connection could work entirely at the MAC
    layer with nonsense IPs (or stealth data transfer ;-0) in the packet
    headers. MACs are important for getting traffic where it is really
    supposed to go, and the IP is only used to find out what the next
    MAC along the line should be. [In practice, unix-type machines
    often -do- go through routing for each packet, as the unix networking
    control structures usually do not keep track of the interface,
    and because routing can change dynamically in the middle of a connection,
    and because you don't necessarily want the reply packets to go out
    the same interface that the original packets came in.]
     
    Walter Roberson, Nov 20, 2004
    #2
    1. Advertisements

  3. DanS

    Erik Freitag Guest

    You might want to try searching any of the many TCP/IP books - my favorite
    is Comer's "Internetworking with TCP/IP" (volume 1).

    To answer your question, a host will just forward the packet to the
    router. A router will decrement the time-to-live field, recompute the
    checksum and forward. No other changes are made to the packet.
     
    Erik Freitag, Nov 20, 2004
    #3
  4. comp.protocols.tcp-ip would be a better place. But first you should
    review the responses you've already received here. Once you've made
    some progress, you'll probably still have questions, and you should ask
    them there.
     
    Barry Margolin, Nov 20, 2004
    #4
  5. DanS

    DanS Guest

    What a great explanation Walter !!! Thank you !!!

    Since my experience with networkng is mostly on the deployment side, and
    not programming, I was under the impression that the IP address of a
    packet is what NIC's listen for, while in reality it's the MAC address.

    Seems as though ARP is the real workhorse here. In this project, I wasn't
    looking to build a full-blown routing application, just enough
    functionality to do reliable packet-forwarding.

    Since there is already a bridging application written for this device, I
    think the code is half way there already for a routing application. Now
    I'm hoping that the SDK has some ARP functionality built into it, it must
    if it has a TCP/IP stach inside.

    Thank you again.

    Regards,

    DanS
     
    DanS, Nov 20, 2004
    #5
  6. DanS

    PES Guest

    While this is entirely true, it should not be overlooked as what the
    routing process itself does. The routing process determinces what the
    next hop is for an ip based packet based on the destination IP address
    and metrics of possible routes. If it is on an ethernet interface it
    will arp the address if the mac address isn't already in the arp table.
    If the next hop is out a serial interface or such, an arp may not be
    required. The equivalent on a frame relay may be a frame relay map, on
    hdlc the interface assumes reachablility for any ip address on its
    subnet and forwards anything that is next hop on its associated subnet
    blindly. I also might add that Walter probably spent a significant
    amount of time and done a very good job of explaining how packets are
    routed. I would also like to recommend a book called TCP/IP Unleased by
    Karanjit Siyan and Tim Parker which is the best book I've ever read on
    TCP/IP fundamentals.
     
    PES, Nov 20, 2004
    #6
  7. : If the next hop is out a serial interface or such, an arp may not be
    :required. The equivalent on a frame relay may be a frame relay map, on
    :hdlc the interface assumes reachablility for any ip address on its
    :subnet and forwards anything that is next hop on its associated subnet
    :blindly.

    Good points about other kinds of interfaces. We have had non-ethernet
    transports here, so I should have known better, but we went ethernet
    on our WAN interface long enough ago that I fell into the "everything
    is ethernet" trap.

    : I also might add that Walter probably spent a significant
    :amount of time and done a very good job of explaining how packets are
    :routed.

    The key role of MAC addresses was a real revelation to me when
    it finally sunk in. I knew MACs existed and I knew they were useful
    somehow, but it took years of having seen the MACs in packet headers
    before I caught on to what they really did instead of thinking of them
    as some archaic artifact of no real consequence that were left over
    from an earlier age. I should have read a good IP book years before!

    Heck, I should still read a good IP book, so I can wrap my head fully
    around congestion control, slow starts, delayed acks, and the Nagle
    algorithm.


    [I don't have any formal training on anything to do with networking
    or firewalls, with the singular exception that I have a piece of
    paper that claims I'm trained to operate the Nortel Device Manager
    (dm) to configure Baystack 450's and Accelar/Passport 1100's and 1200's.]
     
    Walter Roberson, Nov 20, 2004
    #7
  8. DanS

    DanS Guest

    Thanks Barry, I didn't think to filter on 'protocols' in the newsgroup
    list, and the 2 I posted too seemed to me to be the most relevant.

    And yes, any more in-depth question's I will ask there.

    Regards,

    DanS
     
    DanS, Nov 20, 2004
    #8
  9. DanS

    DanS Guest

    -cnrc.gc.ca (Walter Roberson) wrote in
    I don't think a different kind of interface is an issue with my current
    project, so I'm not really concerned with that.
    I agree completely, and I thought I did gives kudo's to that. I have the
    same habit of trying to answer question's in depth. It kind of bug's me
    when people spend a good amount of time writing a post explaining their
    problems/questions in depth and all the replies are simple 1 or 2 liner's
    that 1) either don't actually answer the question, or 2) do answer a
    question, but give absolutely no background on to why that is the answer.
    I'm not saying every post should be a giant lecture, but a little detail
    is good.
    Walter, your explanation was a revelation to me as well, 'it all makes
    sense now' ! Well..all question's can't be answered now, but it truly
    does answer many other questions I may have had.
    I unfortunately don't have any 'formal' training either. I say
    unfortunate not because I lack any knowledge, but because it's hard to
    convince anyone that doesn't know you that you are capable of handling a
    position. In the job I had before my current one, I started off in the
    lab as a top-level engineering aide.

    I originally got the position because I knew someone on the inside. After
    2 months, they needed some extra bodies on the road for a state-wide
    private wireless IP network deployment. So I transferred department's,
    which bumped up my salary. After about a month on the ground, I took over
    as the lead technical guy on the project because of my PROVEN
    performance, which bumped my salary up again. Hell, when I programmed my
    first Cisco router, I was sitting in a tower shack on a mountain in
    Montana in the middle of January working from document's found on the
    internet that I had printed out. When the project was over, I was back
    working on the inside again. Over the next 4 months there was MAJOR staff
    cutting. Out of 150 people, I was one of the last 20 remaining staff
    members. I was also one of the last one's hired originally. At that
    point, I was the IT department, mechanical designer, the network scenario
    test guy and beta test manager. Inevitably, the company folded and I was
    out of work.

    Because I didn't have any of those 'certifications' or a degree, I
    couldn't find any job in a computer field other than a $12/hr. PC
    technician (and most of them wanting A-Plus certification (which IMO is
    outdated anyway in modern PC's). I've been in the wireless data
    communication's and networking field since 1983. I've learned EVERYTHING
    I know through doing, in real-world situation's, with real-world
    consequences. It's just unfortunate that almost all position's, from what
    I can tell, go through recruiter's nowadays. I know that I could have
    landed something respectable, if I could have gotten past the recruiters,
    and actually talk to the HR people of the respective companies. I'm sure
    the in-the-toilet job market in Western NY has something to do with it as
    well (if I could only convince the wife to move somewhere else (ie-
    warmer).

    Thanks for letting me gripe.

    Regards,

    DanS
     
    DanS, Nov 20, 2004
    #9
  10. DanS

    stephen Guest

    Agreed - the original readable book on how IP actually works.

    Also, one of the 2 other volumes has complete source code for an IP stack +
    router - may help you understnad any other issues that come up......
     
    stephen, Nov 21, 2004
    #10
  11. DanS

    Hansang Bae Guest

    [snip]
    I find that people know TCP/IP and then there are people who *really*
    know TCP/IP.

    It really does help if you can wrap your head around Stevens' book.

    --

    hsb

    "Somehow I imagined this experience would be more rewarding" Calvin
    *************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
    ********************************************************************
    Due to the volume of email that I receive, I may not not be able to
    reply to emails sent to my account. Please post a followup instead.
    ********************************************************************
     
    Hansang Bae, Nov 25, 2004
    #11
  12. DanS

    Erik Freitag Guest

    According to the title page, that would be Comer's & Stevens' book.
     
    Erik Freitag, Nov 25, 2004
    #12
  13. DanS

    Hansang Bae Guest

    I like them both. I find that Comer is more academic than Stevens.
    Both are excellent but Stevens has more clear examples in his book.


    --

    hsb

    "Somehow I imagined this experience would be more rewarding" Calvin
    *************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
    ********************************************************************
    Due to the volume of email that I receive, I may not not be able to
    reply to emails sent to my account. Please post a followup instead.
    ********************************************************************
     
    Hansang Bae, Nov 25, 2004
    #13
  14. DanS

    Erik Freitag Guest

    Sorry I wasn't clear. I thought you were talking about Volume 2 of
    "Internetwork with TCP/IP". Both Comer and Stevens are authors of that
    book.
     
    Erik Freitag, Nov 25, 2004
    #14
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.