Thanks a lot for all your answers buddies
Got to make sum important points
At the end of the day i still feel tat icmp is still whether control plane
nor data plane???
hehehheheheh :)
On Mon, Nov 15, 2010 at 12:39 AM, Dale Shaw <dale.shaw_at_gmail.com> wrote:
> I concur with Sadiq's assessment.
>
> In terms of the way ICMP traffic is classified (control vs data) from
> the perspective of a router, it depends entirely on whether it is
> destined for that router or simply being passed through it.
>
> I can't think of a ICMP packet type that triggers a response by an
> intermediate/transit system, aside from oddball things like IDS/IPS.
> Can anyone else? By design, It's all about signalling to/from
> endpoints.
>
> And the PAK priority thing doesn't hold water either as last time I
> checked (12.4(15)T), IKE traffic - very much a control plane protocol
> when a SA is terminated on the local router - wasn't given any special
> treatment (no PAK priority, no DSCP marking).
>
> Happy to stand corrected.
>
> Cheers
> Dale
> (apologies for top-post and lack of quoting and trimming)
>
>
> On Monday, November 15, 2010, Marko Milivojevic <markom_at_ipexpert.com>
> wrote:
> > Of course, based on the assumption that Cisco documentation is never
> > wrong, a very wise choice.
> >
> > --
> > Marko Milivojevic - CCIE #18427
> > Senior Technical Instructor - IPexpert
> >
> > FREE CCIE training: http://bit.ly/vLecture
> >
> > Mailto: markom_at_ipexpert.com
> > Telephone: +1.810.326.1444
> > Web: http://www.ipexpert.com/
> >
> > On Sun, Nov 14, 2010 at 02:13, ron wilkerson <ron.wilkerson_at_gmail.com>
> wrote:
> >> that's fine..
> >> i'll stick to what the cisco doc states and others can stick to what
> they
> >> believe is correct...agree to disagree.
> >>
> >> another item to be added to the list where everyone won't agree due to
> >> various reasons.
> >>
> >>
> >>
> >> On Sat, Nov 13, 2010 at 7:10 PM, Tyson Scott
> >> <tyson.scott_at_advtechracks.com>wrote:
> >>
> >>> As I said ICMP unreachables will go to the CEF exception sub interface
> >>>
> >>> Regards,
> >>>
> >>> Tyson Scott
> >>> CCIE # 13513 (R&S, Security, SP)
> >>>
> >>> Managing Partner/Technical Instructor - IPexpert Inc.
> >>> tscott_at_ipexpert.com
> >>>
> >>>
> >>> ----- Reply message -----
> >>> From: "ron wilkerson" <ron.wilkerson_at_gmail.com>
> >>> Date: Sat, Nov 13, 2010 3:30 pm
> >>>
> >>> Subject: ICMP Query!!!
> >>> To: "Tyson Scott" <tyson.scott_at_advtechracks.com>
> >>> Cc: "negron.paul_at_gmail.com" <negron.paul_at_gmail.com>, "tron_at_huapi.ba.ar"
> <
> >>> tron_at_huapi.ba.ar>, "eliteccie_at_gmail.com" <eliteccie_at_gmail.com>, "
> >>> ccielab_at_groupstudy.com" <ccielab_at_groupstudy.com>
> >>>
> >>>
> >>>
> http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd805ffde8.html
> >>>
> >>> read the 4th paragraph.
> >>>
> >>> On Sat, Nov 13, 2010 at 3:24 PM, Tyson Scott <
> tyson.scott_at_advtechracks.com
> >>> > wrote:
> >>>
> >>>> ICMP is not control plane traffic. B ICMP unreachables go to the CEF
> >>>> exception for example. B Consider the control plane as protocols that
> >>>> glue the network together. B ICMP traffic to the router go to the host
> >>>> control plane because of being directed to the device thus it must
> >>>> handle it. B ICMP is data traffic that may be used for management
> >>>> purposes
> >>>>
> >>>> Regards,
> >>>>
> >>>> Tyson Scott
> >>>> CCIE # 13513 (R&S, Security, SP)
> >>>> Managing Partner/Technical Instructor - IPexpert Inc.
> >>>> tscott_at_ipexpert.com
> >>>>
> >>>>
> >>>> ----- Reply message -----
> >>>> From: "Paul Negron" <negron.paul_at_gmail.com>
> >>>> Date: Sat, Nov 13, 2010 2:10 pm
> >>>> Subject: ICMP Query!!!
> >>>> To: "ron.wilkerson_at_gmail.com" <ron.wilkerson_at_gmail.com>, "Carlos G
> >>>> Mendioroz" <tron_at_huapi.ba.ar>
> >>>> Cc: "CCIE KID" <eliteccie_at_gmail.com>, "Cisco certification"
> >>>> <ccielab_at_groupstudy.com>
> >>>>
> >>>>
> >>>> Very Interesting Response.
> >>>>
> >>>> I guess I primarily viewed ICMP as testing the Control Plane/ Data
> Plane
> >>>> with the Majority of ICMP Query types:
> >>>>
> >>>> * 0 = Echo Reply (3ping response2)
> >>>> * 8 = Echo Request (3ping query2)
> >>>> * 9 = Router Advertisement (RFC 1256)
> >>>> * 10 = Router Solicitation (RFC 1256)
> >>>> * 13 = Time Stamp Request
> >>>> * 14 = Time Stamp Reply
> >>>> * 17 = Address Mask Request
> >>>> * 18 = Address Mask Reply
> >>>>
> >>>> I know my definition is a little Narrow but it does help differentiate
> >>>> ICMP
> >>>> from protocols like RSVP, PIM, EIGRP that strictly represent Control
> Plane
> >>>> from a Routing Switching perspective.
> >>>>
> >>>> As far as the view that because ICMP uses the CPU being a CLEAR
> >>>> definition,
> >>>> this I would disagree with. What would Process Switching be then?
> Control
> >>>> Plane or Data Plane activity?
> >>>>
> >>>> Carlos and Ron do make a good point to expand my Narrow definition
> though.
> >>>> :-)
> >>>>
> >>>> Paul
> >>>>
> >>>>
> >>>> --
> >>>> Paul Negron
> >>>> CCIE# 14856 CCSI# 22752
> >>>> Senior Technical Instructor
> >>>> www.micronicstraining.com
> >>>>
> >>>>
> >>>>
> >>>> > From: <ron.wilkerson_at_gmail.com>
> >>>> > Reply-To: <ron.wilkerson_at_gmail.com>
> >>>> > Date: Fri, 12 Nov 2010 23:58:17 +0000
> >>>> > To: Paul Negron <negron.paul_at_gmail.com>, Carlos G Mendioroz <
> >>>> tron_at_huapi.ba.ar>
> >>>>
> >>>> > Cc: CCIE KID <eliteccie_at_gmail.com>, Cisco certification
> >>>> > <ccielab_at_groupstudy.com>
> >>>> > Subject: Re: ICMP Query!!!
> >>>> >
> >>>> > Agree with carlos...
> >>>> > I've always thought of control plane as anything that the cpu has to
> >>>> look at.
> >>>> > Some icmp packets require the cpu, so I'd classify those icmp as
> control
> >>>> plane
> >>>> > packets.
> >>>> >
> >>>> >
> >>>> > Sent from my Verizon Wireless BlackBerry
> >>>> >
> >>>> > -----Original Message-----
> >>>> > From: Paul Negron <negron.paul_at_gmail.com>
> >>>> > Sender: nobody_at_groupstudy.com
> >>>> > Date: Fri, 12 Nov 2010 16:39:10
> >>>> > To: Carlos G Mendioroz<>>> >>> I apologize, B I meant to state:
> >>>> >>>
> >>>> >>>> IGMP packets are used to create state on the Router that receives
> >>>> them.
> >>>> >>>> Since it is used to create state, it is a part of the Control
> Plane
> >>>> >>>> process.
> >>>> >>>> It joins so that trees can be built, Although it is PIM that
> builds
> >>>> them.
> >>>> >>>>
> >>>> >>>> ICMP is generating traffic and is not associated with building
> >>>> ANYTHING. It
> >>>> >>>> is considered Data Plane traffic. It uses paths that have already
> >>>> been
> >>>> >>>> setup
> >>>> >>>> by a Control Plane Protocol, like OSPF or EIGRP or PIM for that
> >>>> matter.
> >>>> >>>
> >>>> >>> I accidentally stated ICMP twice.
> >>>> >>>
> >>>> >>> Paul
> >>>> >>
> >>>> >> --
> >>>> >> Carlos G Mendioroz B <tron_at_huapi.ba.ar> B LW7 EQI B Argentina
> >>>> >
> >>>> >
> >>>> > Blogs and organic groups at http://www.ccie.net
> >>>> >
> >>>> >
> _______________________________________________________________________
> >>>> > Subscription information may be found at:
> >>>> > http://www.groupstudy.com/list/CCIELab.html
> >>>>
> >>>>
> >>>> Blogs and organic groups at http://www.ccie.net
> >>>>
> >>>>
> _______________________________________________________________________
> >>>> Subscription information may be found at:
> >>>> http://www.groupstudy.com/list/CCIELab.html
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> stop talking
> >>>
> >>
> >>
> >>
> >> --
> >> stop talking
> >>
> >>
> >> Blogs and organic groups at http://www.ccie.net
> >>
> >> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
> >
>
-- With Warmest Regards, CCIE KID IN PURSUIT OF CCIE Blogs and organic groups at http://www.ccie.netReceived on Mon Nov 15 2010 - 00:49:03 ART
This archive was generated by hypermail 2.2.0 : Sun Dec 05 2010 - 22:14:56 ART