From: Yves Fauser (Yves@xxxxxxxxx)
Date: Mon Aug 13 2001 - 13:11:00 GMT-3
Hi Chuck,
sorry for the confusing wording, the multicast MAC Address is only in
the
ethernet frame, not in the PDU. I got it from a sniffer trace :
- - - - - - - - - - - - - - - - - - - - Frame 1 - - - - - - - - - - -
- - - -
- -
Frame Source Address Dest. Address Size Rel. Time Delta
Time
Abs.
1 Cisco107AC01 0180C2000015 1514 000:00:00.000
0.000.000
13.0
DLC: ----- DLC Header -----
DLC:
DLC: Frame 1 arrived at 17:52:28.8965; frame size is 1514
(05EA hex)
byte
DLC: Destination = Multicast 0180C2000015
DLC: Source = Station Cisco107AC01
DLC: 802.3 length = 1500
DLC:
LLC: ----- LLC Header -----
LLC:
LLC: DSAP Address = FE, DSAP IG Bit = 00 (Individual Address)
LLC: SSAP Address = FE, SSAP CR Bit = 00 (Command)
LLC: Unnumbered frame: UI
LLC:
IS-IS: ----- ISO Network Layer Header -----
IS-IS:
IS-IS: Protocol ID = 83 (Intermediate System Routing Exchange
Protocol)
IS-IS: Header length = 27
IS-IS: Version / Protocol ID Extension = 1
IS-IS: ID Length = 0, Indicates 6 Octets
IS-IS: PDU type = 16 (Hello, LAN Level 2)
IS-IS: Version = 1
IS-IS: Reserved = 0
IS-IS: Maximum Area Addesses = 0
IS-IS: Circuit Type = 2 (Level 2 routing only)
IS-IS: Source ID = 138002254003
IS-IS: Holding time is 10 second(s)
IS-IS: Frame length is 1497 byte(s)
IS-IS: Designated Intermediate System for Level 2
IS-IS: Priority = 64
IS-IS: Address = 138002254003
IS-IS: ID = 01
IS-IS:
IS-IS: ----- ISO Network Layer Variable Fields -----
IS-IS:
IS-IS: Variable field:
IS-IS: Field Code = 129 (Protocols Supported)
IS-IS: Field length = 1
IS-IS: NLPID's for protocols within this IS:
IS-IS: NLPID = CC (Internet IP)
IS-IS: Variable field:
IS-IS: Field Code = 1 (Manual Area Addresses)
IS-IS: Field length = 4
IS-IS: Manual Area Address:
IS-IS: Length = 3
IS-IS: Format = 49 (Local Binary)
IS-IS: Address = 490003
IS-IS: Variable field:
IS-IS: Field Code = 132 (IP Interface Address)
IS-IS: Field length = 8
IS-IS: IP Interface Address:
IS-IS: IP Address = [138.2.136.1]
IS-IS: IP Address = [134.247.0.254]
IS-IS: Variable field:
IS-IS: Field Code = 8 (Padding)
IS-IS: Field length = 255
IS-IS: Variable field:
IS-IS: Field Code = 8 (Padding)
IS-IS: Field length = 255
IS-IS: Variable field:
IS-IS: Field Code = 8 (Padding)
IS-IS: Field length = 255
IS-IS: Variable field:
IS-IS: Field Code = 8 (Padding)
IS-IS: Field length = 255
IS-IS: Variable field:
IS-IS: Field Code = 8 (Padding)
IS-IS: Field length = 255
IS-IS: Variable field:
IS-IS: Field Code = 8 (Padding)
IS-IS: Field length = 164
I just light read the RFC and iso spec. I realy don't think we will see
isis on
the core of our ccie lab network. If it is in the lab, I think we'll
find it
from border to border. Most likely we will have to tunnel it.
Yves
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
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:31:50 GMT-3