From: Pavel Bykov (slidersv@gmail.com)
Date: Sun Jan 25 2009 - 10:46:55 ARST
Well, session is usually L4.
Like
Router1 - BGP - Router2 = Session1
Router1 - Telnet - Router2 = Session2
Router1 - FTP - Router2 = Session3
But from IP-address pair that the mechanism is considering it will always be
only one source-destination pair.
So session would not be correct term to describe it.
On Thu, Jan 22, 2009 at 8:29 AM, shiran guez <shiranp3@gmail.com> wrote:
> it is not exactly that the the router is not telling you, it is a simple
> miss in the definition as the load sharing is done by default session based
> and you can change it to packet based.
>
> so the command should have been:
>
> ROUTER(config-if)#ip load-sharing ?
> per-session Deterministic distribution
> per-packet Random distribution
>
> :-)
>
>
>
>
> On Tue, Jan 20, 2009 at 12:28 PM, joshua atterbury <
> joshuaatterbury@gmail.com> wrote:
>
>> Hi Pavel,
>>
>> Correct, The output of your command shows that cef is using the "per
>> destination" load balancing mechanism, What the router is not telling
>> you,
>> is that the hash process for per destination uses the source and
>> destination
>> address of the packet, This allows the device to perform a "fairer" load
>> balancing process.
>>
>> Check this link,
>>
>> http://www.cisco.com/en/US/products/hw/modules/ps2033/prod_technical_reference09186a00800afeb7.htmlWith
>> specific attention to this statement
>>
>> "For per destination load balancing a hash is computed out of the source
>> and
>> destination IP address. This hash points to exactly one of the adjacency
>> entries in the adjacency table, providing that the same path is used for
>> all
>> packets with this source/destination address pair"
>>
>> So as you mentioned, the source interface does not play a part, But the
>> source address does infact influence the load-balancing process.
>> This all came to light when I had issues with traffic being black-holed
>> and
>> had to investigate how/why
>>
>> Cheers.
>> Josh
>> On Tue, Jan 20, 2009 at 9:07 PM, Pavel Bykov <slidersv@gmail.com> wrote:
>>
>> > Also:
>> > Rack1R4(config-if)#ip load-sharing ?
>> > per-destination Deterministic distribution
>> > per-packet Random distribution
>> >
>> >
>> > Where did you get that information? Aren't you confusing CEF with
>> > Etherchannel?
>> >
>> >
>> > On Tue, Jan 20, 2009 at 9:21 AM, joshua atterbury <
>> > joshuaatterbury@gmail.com> wrote:
>> >
>> >> Take care to remember that cef uses the source ip and destination ip
>> for
>> >> the hashing process, To view the route that cef would take for a
>> particular
>> >> Src/Dst group use the following command
>> >>
>> >> show ip cef exact-route SRC DST
>> >>
>> >> Cheers
>> >> Josh
>> >>
>> >> On Tue, Jan 20, 2009 at 5:12 PM, Pavel Bykov <slidersv@gmail.com>
>> wrote:
>> >>
>> >>> Well, router chooses not source interface, but output interface. When
>> the
>> >>> packet came into interface, it can either drop it ( e.g. based on
>> uRPF)
>> >>> or
>> >>> process it.
>> >>> In any case, output interface selection on not per-packet basis
>> >>> (per-packet
>> >>> is round-robin) is usually done per hash. I.E. you input something in,
>> >>> and
>> >>> the output is hash.
>> >>>
>> >>> This is really a CEF thing, which you should read in to if you're
>> >>> interested.
>> >>> For example:
>> >>>
>> >>> OSPF finds out that there are 3 equal paths to a destination network
>> >>> 150.1.146.0, so this is programmed into CEF. Output interfaces are
>> Serial
>> >>> 0/1, 0/2 and 0/3
>> >>> CEF has 16 table entries, which CEF fills in the following fasion:
>> >>> 00: Serial 0/1
>> >>> 01: Serial 0/2
>> >>> 02: Serial 0/3
>> >>> 03: Serial 0/1
>> >>> 04: Serial 0/2
>> >>> 05: Serial 0/3
>> >>> 06: Serial 0/1
>> >>> 07: Serial 0/2
>> >>> 08: Serial 0/3
>> >>> 09: Serial 0/1
>> >>> 10: Serial 0/2
>> >>> 11: Serial 0/3
>> >>> 12: Serial 0/1
>> >>> 13: Serial 0/2
>> >>> 14: Serial 0/3
>> >>> 15: Serial 0/1
>> >>>
>> >>>
>> >>> The packet comes into a router (through any interface, no uRPF).
>> >>> Destination
>> >>> is 150.1.146.56. Hash is run (I'm don't exactly know the algorithm).
>> Hash
>> >>> outptut is always 4 bits, therefore output will be from 00 to 15, and
>> it
>> >>> will correspond to CEF table entry. Let's say for 150.1.146.56 hash
>> >>> outputs
>> >>> 09.
>> >>> 09 is looked up, and it corresponds to output interface Serial 0/1, so
>> >>> packet is sent out using interface Serial 0/1.
>> >>>
>> >>> Next packet is let's say destined to 150.1.146.182. Hash for that
>> >>> destination is 03. Output interface is Serial 0/1... again! So no load
>> >>> balancing this time.
>> >>> So you can see that load balancing really depends on quality of hash
>> >>> algorithm.
>> >>>
>> >>>
>> >>> On Tue, Jan 20, 2009 at 6:47 AM, Sidda6 <sidda6@gmail.com> wrote:
>> >>>
>> >>> > From your explanation I understood my scenario is by default using
>> >>> > per-destination load balancing. So, how does router determines
>> source
>> >>> > interface for the packet here ( with per-destination ) .. does it
>> pick
>> >>> > randomly any one of two interfaces or is there there any specific
>> >>> > criteria. ( Is there anything ARP cache plays role here with respect
>> >>> > to picking up of source interface of packet)
>> >>> >
>> >>> > On Mon, Jan 19, 2009 at 3:30 PM, Pavel Bykov <slidersv@gmail.com>
>> >>> wrote:
>> >>> > > Default max-paths is 4 for all except BGP, (which is 1) so command
>> is
>> >>> not
>> >>> > > needed.
>> >>> > > If IP route outputs two destinations, the load balancing is taking
>> >>> place.
>> >>> > > Usually, CEF will do per destination load balancing.
>> >>> > > Setting on the interface defines the method and can be per packet
>> >>> > (depends
>> >>> > > on platform)
>> >>> > >
>> >>> > > for information about CEF tables, use:
>> >>> > >
>> >>> > > "show ip cef 155.1.146.0 internal"
>> >>> > >
>> >>> > > So, to be exact and answer your questions:
>> >>> > > 1. Depends on the method, per packet or per destination. Packets
>> are
>> >>> load
>> >>> > > balanced
>> >>> > > 2. Not required.
>> >>> > >
>> >>> > > On Mon, Jan 19, 2009 at 8:24 AM, Sidda6 <sidda6@gmail.com> wrote:
>> >>> > >>
>> >>> > >> I have route to 155.1.146.6 from my route table: route table
>> looks
>> >>> like
>> >>> > >> this->
>> >>> > >>
>> >>> > >> R5# show ip route
>> >>> > >> O IA 155.1.146.0 [110/65] via 150.1.0.4, 00:01:26,
>> Serial0/0/0
>> >>> > >> [110/65] via 150.1.0.1, 00:01:26, Serial0/0/0
>> >>> > >>
>> >>> > >> R5#show ip route 155.1.146.6
>> >>> > >> Routing entry for 155.1.146.0/24
>> >>> > >> Known via "ospf 1", distance 110, metric 65, type inter area
>> >>> > >> Last update from 150.1.0.4 on Serial0/0/0, 00:04:06 ago
>> >>> > >> Routing Descriptor Blocks:
>> >>> > >> 150.1.0.4, from 160.1.4.4, 00:04:06 ago, via Serial0/0/0
>> >>> > >> Route metric is 65, traffic share count is 1
>> >>> > >> * 150.1.0.1, from 160.1.1.1, 00:04:06 ago, via Serial0/0/1
>> >>> > >> Route metric is 65, traffic share count is 1
>> >>> > >>
>> >>> > >> 1. what happens with OSPF path selection to destination network
>> when
>> >>> > >> we have multiple equal costs...which path it selects in my case?
>> if
>> >>> it
>> >>> > >> selected Serial0/0/1.. why it did not picked even Serial0/0/0 has
>> >>> > >> equal cost.
>> >>> > >> 2. Do i need to use max-paths command to load maximum-paths to
>> >>> > >> loadbalance between two interfaces?
>> >>> > >>
>> >>> > >> Regards,
>> >>> > >> Sidda
>> >>> > >>
>> >>> > >>
>> >>> > >> Blogs and organic groups at http://www.ccie.net
>> >>> > >>
>> >>> > >>
>> >>>
>> _______________________________________________________________________
>> >>> > >> Subscription information may be found at:
>> >>> > >> http://www.groupstudy.com/list/CCIELab.html
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >
>> >>> > >
>> >>> > >
>> >>> > > --
>> >>> > > Pavel Bykov
>> >>> > > ----------------
>> >>> > > Don't forget to help stopping the braindumps, use of which reduces
>> >>> value
>> >>> > of
>> >>> > > your certifications. Sign the petition at
>> >>> http://www.stopbraindumps.com/
>> >>> > >
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Pavel Bykov
>> >>> ----------------
>> >>> Don't forget to help stopping the braindumps, use of which reduces
>> value
>> >>> of
>> >>> your certifications. Sign the petition at
>> http://www.stopbraindumps.com/
>> >>>
>> >>>
>> >>> Blogs and organic groups at http://www.ccie.net
>> >>>
>> >>>
>> _______________________________________________________________________
>> >>> Subscription information may be found at:
>> >>> http://www.groupstudy.com/list/CCIELab.html
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >
>> >
>> > --
>> > Pavel Bykov
>> > ----------------
>> > Don't forget to help stopping the braindumps, use of which reduces value
>> of
>> > your certifications. Sign the petition at
>> http://www.stopbraindumps.com/
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Shiran Guez
> MCSE CCNP NCE1 JNCIA-ER CCIE #20572
> http://cciep3.blogspot.com
> http://www.linkedin.com/in/cciep3
>
-- Pavel Bykov ---------------- Don't forget to help stopping the braindumps, use of which reduces value of your certifications. Sign the petition at http://www.stopbraindumps.com/Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:40 ARST