From: shiran guez (shiranp3@gmail.com)
Date: Sun Jan 25 2009 - 11:02:51 ARST
Well, not exactly true session (OSI model is layer 5)
session definition is a dialogue between two or more communicating devices.
TCP / UDP session is a set of src.ip + src.port to dst.ip + dst.port
On Sun, Jan 25, 2009 at 2:46 PM, Pavel Bykov <slidersv@gmail.com> wrote:
> 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/
>
-- Shiran Guez MCSE CCNP NCE1 JNCIA-ER CCIE #20572 http://cciep3.blogspot.com http://www.linkedin.com/in/cciep3Blogs 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