1)Improperly configured keepalivess
2) Mismatched the encapsulation types

Which one can be cause the link flapping (or both)?

THANK

Report this post to a moderator

that depends. can your flapping link pass traffic at all? if it can pass
traffic while it's in the "UP" state of a flapping link, i think that would
make #2 incorrect. if the encapsulation types were different, it shouldnt
pass any traffic at all. in that case, i would lean towards answer (1)

however, if it can't pass any traffic at all regaurdless of the state of the
link, I think it could be either (ie, both could be the correct answer).

anyone else?


thanks,
-Brad Ellis
CCIE#5796 (R&S / Security)
Network Learning Inc
brad at eccie.com
www.ccbootcamp.com/quicklinks.html (Cisco Training)
www.routerie.com (Cisco R&S CCIE Discussion groups)
www.securityie.com (Cisco Security CCIE Discussion groups)
www.optsys.net (Cisco hardware)

"Benny" <noname_00@mail.hongkong.com> wrote in message
news:6c57425a.0403272113.5a99507@posting.google.com...
> 1)Improperly configured keepalivess
> 2) Mismatched the encapsulation types
>
> Which one can be cause the link flapping (or both)?
>
> THANK

Report this post to a moderator

Chiming in.

Console output messages will indicate "up" then "down" then "up"
and "down" repeatedly depending upon what "kind" of encapsulation error
is occurring. However, data will no pass regardless, even in the
short periods were the router indicates 'up.' These are just short
instances where heartbeats/keepalives are trying to determine what
the scoop is. Because the console messages are changing,
some people may consider this "flapping."
I do not. The link is down and not passing traffic, period.
So, item number 2, encapsulation error, Is_Incorrect.
(I would not be surprised, however, if the test creator would
accept this as a correct answer because of the console messages.)



Item number 1, mismatched timers,
can certainly cause flapping in the sense that a link
becomes unstable - usable 1 minute and not usable the next.



-ja



"Brad" <brad@nospam.com> wrote in message
news:rtK9c.7403$Rh.377@fed1read05...
> that depends. can your flapping link pass traffic at all? if it can pass
> traffic while it's in the "UP" state of a flapping link, i think that
would
> make #2 incorrect. if the encapsulation types were different, it shouldnt
> pass any traffic at all. in that case, i would lean towards answer (1)
>
> however, if it can't pass any traffic at all regaurdless of the state of
the
> link, I think it could be either (ie, both could be the correct answer).
>
> anyone else?
>
>
> thanks,
> -Brad Ellis
> CCIE#5796 (R&S / Security)
> Network Learning Inc
> brad at eccie.com
> www.ccbootcamp.com/quicklinks.html (Cisco Training)
> www.routerie.com (Cisco R&S CCIE Discussion groups)
> www.securityie.com (Cisco Security CCIE Discussion groups)
> www.optsys.net (Cisco hardware)
>
> "Benny" <noname_00@mail.hongkong.com> wrote in message
> news:6c57425a.0403272113.5a99507@posting.google.com...
>
>

Report this post to a moderator

Welps,

Actualy some routing protocols such as bgp actualy take flaping into
acount and ad a penalty and a half life time into play. Being that
BGP uses TCP for transport and its peering proccess. I would thing
that flaping would be specificly a state where in the link is reported
UP then Down and Up etc etc to the whatever is making the desision to
put it in the routing table so this would almost always asume for a
link to be flaping that it must be passing at least the enough info to
make the link look up for a period of time for the routing protocol to
consider it up. IF you use lie static routes the link can be in an
Up / Down state and still attempt to forward traffic even though it
doesnt get to the other end so that isnt realy flapping as defined in
most books

Thats just my thought
On Sun, 28 Mar 2004 19:05:48 -0600, "John Agosta"
<j_agosta@remove_wideopenwest.kom> wrote:

>Chiming in.
>
>Console output messages will indicate "up" then "down" then "up"
>and "down" repeatedly depending upon what "kind" of encapsulation error
>is occurring. However, data will no pass regardless, even in the
>short periods were the router indicates 'up.' These are just short
>instances where heartbeats/keepalives are trying to determine what
>the scoop is. Because the console messages are changing,
>some people may consider this "flapping."
>I do not. The link is down and not passing traffic, period.
>So, item number 2, encapsulation error, Is_Incorrect.
>(I would not be surprised, however, if the test creator would
>accept this as a correct answer because of the console messages.)
>
>
>
>Item number 1, mismatched timers,
> can certainly cause flapping in the sense that a link
>becomes unstable - usable 1 minute and not usable the next.
>
>
>
>-ja
>
>
>
>"Brad" <brad@nospam.com> wrote in message
>news:rtK9c.7403$Rh.377@fed1read05...
>would
>the
>

Report this post to a moderator

In article < ji0f6097guh76c3rh4c1dgsgucn7u5
v1g6@4ax.com>,
tylerkewl@yahoo.com says...
> Welps,
>
> Actualy some routing protocols such as bgp actualy take flaping into
> acount and ad a penalty and a half life time into play. Being that
> BGP uses TCP for transport and its peering proccess. I would thing
> that flaping would be specificly a state where in the link is reported
> UP then Down and Up etc etc to the whatever is making the desision to
> put it in the routing table so this would almost always asume for a
> link to be flaping that it must be passing at least the enough info to
> make the link look up for a period of time for the routing protocol to
> consider it up. IF you use lie static routes the link can be in an
> Up / Down state and still attempt to forward traffic even though it
> doesnt get to the other end so that isnt realy flapping as defined in
> most books
>
> Thats just my thought

Kind of hard to follow the above, but I'll try to respond (hope I read
your msg correctly)

BGP can penalize peers that go up and down (for whatever reason). But
If the link is up enough for the hello's to get by, BGP will not know
that the underlying pipe is having an issue. Not likely but it can
happen.

Also, when an interface is up/down, any routes pointing to it should
disappear. There are bugs in FR code when using subinterfaces, but
generally, up/down interfaces do not come into play when routing
decisions are made.

--

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.
******************************
******************************
********

Report this post to a moderator

I think for the purpose of thios discussion, we are talking about
a 'link' in terms of layer 2 protocol. We are not talking about route flaps
and routing protocols.



<tylerkewl@yahoo.com> wrote in message
news:ji0f6097guh76c3rh4c1dgsgu
cn7u5v1g6@4ax.com...
> Welps,
>
> Actualy some routing protocols such as bgp actualy take flaping into
> acount and ad a penalty and a half life time into play. Being that
> BGP uses TCP for transport and its peering proccess. I would thing
> that flaping would be specificly a state where in the link is reported
> UP then Down and Up etc etc to the whatever is making the desision to
> put it in the routing table so this would almost always asume for a
> link to be flaping that it must be passing at least the enough info to
> make the link look up for a period of time for the routing protocol to
> consider it up. IF you use lie static routes the link can be in an
> Up / Down state and still attempt to forward traffic even though it
> doesnt get to the other end so that isnt realy flapping as defined in
> most books
>
> Thats just my thought
> On Sun, 28 Mar 2004 19:05:48 -0600, "John Agosta"
> <j_agosta@remove_wideopenwest.kom> wrote:
>
pass[color=blue]
shouldnt[color=blue]
of[color=blue]
answer).[color=blue]
>

Report this post to a moderator