From: Peter Van Oene (pvo@xxxxxxxxxxxx)
Date: Mon Aug 13 2001 - 15:26:30 GMT-3
I was referring to historical proposals for encapsulating ISIS in IP as is done
in OSPF. As far as IP routing goes, IS-IS isn't really picking up steam as m
uch as its continuing to be a widely used SP IGP.
*********** REPLY SEPARATOR ***********
On 8/13/2001 at 1:10 PM Ron.Fuller@3x.com wrote:
>For what its worth, IS-IS over IP is pretty dead as far as I can tell.
>TTL
>is irrelevant due to this being a direct L2 encapsulation. Normal bridge
>loop protection applies.
>
>Really? From what I have heard from some ISPs as well as many of the
>seminars at Networkers and other events, IS-IS is picking up steam as a
>preferred IGP as it can carry IPv6 addresing and may be more desireable
>that OSPF. Can anyone on the list validate/refute either side?
>
>Ron Fuller, CCIE #5851, CCDP, CCNP-ATM, CSS Level 1, CCNP-Voice, MCNE
>3X Corporation
>rfuller@3x.com
>
>
>
>
>"Peter Van Oene" <pvo@usermail.com>
>Sent by: nobody@groupstudy.com
>08/13/01 12:38 PM
>Please respond to "Peter Van Oene"
>
>
> To: ccielab@groupstudy.com
> cc:
> Subject: RE: isis on physical / multipoint interfaces
>
>
>The layer two addresses reserved for ISIS are described in ISO 10589/RFC
>1142. There are multiple addresses reserved for various sets of
>routers. Yves references the AllL2's address.
>
>For what its worth, IS-IS over IP is pretty dead as far as I can tell. TTL
>is irrelevant due to this being a direct L2 encapsulation. Normal bridge
>loop protection applies.
>
>pete
>
>
>
>*********** REPLY SEPARATOR ***********
>
>On 8/13/2001 at 8:17 AM Chuck Larrieu wrote:
>
>>thanks for your post. I found it interesting and a good starting point
>for
>>further research. did you use either of the following resources?
>>
>>the information provided by Rad-Com and their alias protocols.com?
>>
>>http://www.protocols.com/pbook/iso.htm
>>
>>the RFC that deals with IS-IS over IP?
>>
>>ftp://ftp.isi.edu/in-notes/rfc1069.txt
>>
>>I won't say I've read, let alone understood, every word. I was unable to
>>find any indication of a MAC address field in any of the packet formats I
>>looked at. I was curious as to where this information come from? Is that
>a
>>Cisco implementation?
>>
>>Also, I believe that in general frame relay by default doesn't replicate
>>anyone's packets. however, other protocols offer the means to make
>>adjustments based on need. IS-IS has no such tweaks.
>>
>>yes, tunnel interface work. tunnels are point-to-point links. ( unless
>you
>>are one of those rare few who have been able to get a point-to-multipoint
>>tunnel to actually work :-> )IS-IS works fine and dandy over PTP's
>>
>>thanks again. appreciate the sharing.
>>
>>Chuck
>>
>>
>>
>>
>>-----Original Message-----
>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>>Yves Fauser
>>Sent: Monday, August 13, 2001 5:57 AM
>>To: Cox, Bryan; 'ccielab@groupstudy.com'
>>Subject: Re: isis on physical / multipoint interfaces
>>
>>
>>Hi all,
>>
>>jonatale@earthlink.net asked me if an isis clns paket does have a TTL
>>field,
>>so I
>>read some a bit more and came to this conclusion :
>>
>>Isis doesn't use clns at all, isis used it's own packet format (isis PDU,
>>unlike
>>ospf that uses an IP packet). clns has a lifetime field, which is the
>same
>>as a
>>TTL. The isis PDU doesn't have a lifetime field. Isis PDU's also don't
>have
>>a
>>Layer 3 multicast destination address, they only have a MAC multicast
>>address of
>>0180.C200.0015. From my understanding a FR HUB router with a physical or
>>multipoint interface will never "replicate" a isis PDU from Spoke to
>Spoke.
>>Also
>>it is the general rule for a hello packet to find neighbors. A spoke will
>>never be
>>a neighbor of another spoke regardless what you do.
>>
>>jonatale@earthlink.net also came up with the idea of creating a tunnel
>>between the
>>two spokes, this works fine.
>>
>>Yves
>>
>>
>>Yves Fauser wrote:
>>
>>> Bryan,
>>>
>>> I think you are right, we may both have some kind of a IOS Version
>>trouble,
>>> but more likely it will not work on Point-to-Multipoint or Physical FR
>>> interfaces in any Version. I saw a scenario that worked with isis on FR
>>PtM
>>> interfaces (in ECP1), but this scenario had a major difference, one
>spoke
>>was
>>> a level-1 and the other spoke was a level-2 router of another Area. I
>>just
>>> tried it out again, and it works in my home lab. After reading some
>more
>>of
>>> Doyle VolI I think I know why (please correct me if I'm wrong guys).
>>>
>>> Doyle, Page 607 :
>>> "Unlike OSPF ISIS router attached to a broadcast multi-access network
>>> establishes adjacencies with all of its neighbors on the network, not
>>just
>>the
>>> DR. Each Router multicasts its LSP's to all of his neighbors, and the
>DR
>>uses
>>> a system of PDU's called Sequence number PDU's (SNP) to ensure that
>>flooding
>>> is reliable."
>>>
>>> Doyle, Page 608 :
>>> "As the L1 and L2 priorities suggest, separate DR's are elected on a
>>network
>>> for level 1 and level 2."
>>>
>>> In OSPF the DR is like a "route reflector" in BGP. In ISIS the DR is
>only
>>used
>>> to control the Exchange of LSP's between the neighbors. Since the ISIS
>>and
>>> OSPF multicast/unicast will have a TTL of 1, they will die on the FR
>HUB.
>>In
>>> OSPF, when the DR is the HUB, there is no need for the LSA to take 2
>hops
>>> (Reflection). In ISIS it has to take 2 hops to work, and this is not
>>possible
>>> since the TTL is 1. If you have 2 Spokes, one is a level-1 and the
>other
>>is a
>>> level-2 it works, since two separate adjacencies are build. If both are
>>> level-1 or both are level-2, it will not work since the DR concept of
>>ISIS
>>has
>>> no knowledge of NBMA Networks. If you have 3 spokes you can't use this
>>trick
>>> anymore since you must have either 2 level-1 1 level-2 routers ore the
>>> opposite.
>>>
>>> Any comments are more than welcome,
>>>
>>> Good luck, Yves
>>>
>>> "Cox, Bryan" wrote:
>>>
>>> > Group,
>>> >
>>> > I have come to the conclusion that ISIS won't run in a frame-relay
>>> > environment with physical or multipoint interfaces without a
>full-mesh.
>>> > Even with "frame map clns <dlci> broadcast" on the spokes and hub I
>>never
>>> > see the ISIS hellos being received at a spoke from another spoke.
>Thus
>>no
>>> > adjacency is formed between the spokes.
>>> >
>>> > In a full mesh I see the appropriate hellos between all points in the
>>> > frame-relay network. IS-IS forms adjacencies and all routes are
>>installed
>>> > in the table.
>>> >
>>> > Does anybody have any working configs for a hub and spoke environment
>>with
>>> > point-to-multipoint or physical interfaces that they can post that
>say
>>> > otherswise? Or am I on the right track?
>>> >
>>> > Thanks,
>>> >
>>> > Bryan
>>> > San Jose October 25th
>>> > **Please read:http://www.groupstudy.com/list/posting.html
>>> **Please read:http://www.groupstudy.com/list/posting.html
>>**Please read:http://www.groupstudy.com/list/posting.html
>>**Please read:http://www.groupstudy.com/list/posting.html
>**Please read:http://www.groupstudy.com/list/posting.html
>**Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:31:50 GMT-3