From: Higgins, Andrew (Andrew.Higgins@xxxxxxxxxxxxxxxxxxx)
Date: Mon Jun 21 1999 - 19:31:20 GMT-3
Mark,
Not sure if this applies to CLNS routes but what were the sources shown in
the LSDB for the routes that were not getting into the route table?
Comparing it to OSPF I just heard last week of several situations where all
routers has LSDB entries but certain routes were not getting into the route
table. The problem was that the LSA's were being flooded with a source that
was not reachable from the OSPF network. Since a return route was not found
the LSA was kept in the database but its associated route was not added to
the route table. Just wondering if the same thing could be happening with
ISIS.
Andrew
-----Original Message-----
From: Mark, Detrick [mailto:mdetrick@cisco.com]
Sent: Monday, June 21, 1999 12:25 PM
To: Derek Fage; ccielab@groupstudy.com
Subject: Re: ISIS Routing issues
Derek,
I worked on this over the weekend. I have a much better understanding of
this now...
In J Doyle's book it states that you can not go from p-to-p to p-to-m on
clns because depending on the interface type (p-to-p or p-to-m) it sends
different types of hello packets which are not compatible. This can be
verified by doing a debug packet. If a p-to-p interface receives a p-to-m
hellos it will not form an adjacency and vice-versa.
I used p-to-m interfaces all around on my test. I used "fram map clns
statements" and I forced the vertex to be the DR. I was able to get routes
between the spokes and vertex but not between the spokes. I tried
everything to get the routes to go from one spoke to another. It looks like
a split-horizon type of situation, but there are no commands to turn on/off
split-horizon for IS-IS and I don't think split-horizon applies to LS
routing protocols. What was strange to me was that the LSDB was identical
on all three routers, why then was the route table missing routes? So, I
guess I was half right. I couldn't figure it out and after a day's work I
gave up.
Mark Detrick
DSL Business Unit
Cisco Systems
2569 McCabe Way
Irvine, CA 92614
----- Original Message -----
From: Derek Fage <DerekF@itexjsy.com>
To: Derek Fage <DerekF@itexjsy.com>; <ccielab@groupstudy.com>
Sent: Saturday, June 19, 1999 2:22 AM
Subject: RE: ISIS Routing issues
> Thanks Mark,
>
> With debug on I do not see any encaps failures (and I can see the CLNS
> packets going out over the F/R).
>
> I was just interested in why I could not get the mulitipoint interface
> talking to the point-to-point interface. With OSPF you can either change
the
> network types or adjust the timers, but this does not seem to be an
option.
>
> I think I'll leave it for now, I know I can get physical to physical,
p-to-p
> to p-to-p, and p-to-p to physical working, and apparentyle it is possible
to
> get multipoint-to-multipoint from what you say.
>
> Cheers,
>
> Derek...
>
> PS - why did Cisco change the naming of point-to-multipoint to just
> multipoint ?
>
> > -----Original Message-----
> > From: Mark, Detrick [SMTP:mdetrick@cisco.com]
> > Sent: 19 June 1999 02:26
> > To: Derek Fage; ccielab@groupstudy.com
> > Subject: Re: ISIS Routing issues
> >
> > First, this IS absolutely possible. I have done it successfully.
> >
> > Second, you said it yourself: "R2 is a point-to-point interface, and
you
> > cannot use a F/R map statement on this." That is why you must use
p-to-m
> > int on all participating routers that are both the hub and the spokes!
> > You
> > MUST have the map statements on the hub and the spokes for this to work.
> >
> > I wiped out my configs that had this to move on to other things. If I
get
> > time this weekend I will set it up again and send the configs.
> >
> > Just out of curiosity... when you do debugs of the packets (check both
> > sides) see if you get any encapsulation failure messages for the CLNS
> > packets. Encapsulation failure messages mean that the router can't
> > resolve
> > the information neccessary to send the packet. This information is
> > usually
> > contained in the map statement.
> >
> > Mark Detrick
> > DSL Business Unit
> > Cisco Systems
> > 2569 McCabe Way
> > Irvine, CA 92614
> > ----- Original Message -----
> > From: Derek Fage <DerekF@itexjsy.com>
> > To: 'Mark, Detrick' <mdetrick@cisco.com>; <ccielab@groupstudy.com>
> > Sent: Friday, June 18, 1999 3:37 PM
> > Subject: RE: ISIS Routing issues
> >
> >
> > > Mark,
> > >
> > > I' fairly sure that there must be an issue with multipoint f/r
> > interfaces,
> > > that cannot be resolved like OSPF by using the ip ospf network
> > equivalent
> > > (there isn't one).
> > >
> > > R1 S01. is multipoint whereas R2 S0.1 is point-to-point. I can see
where
> > the
> > > issue would be with OSPF, but you do not seem to be able to change the
> > > interface characteristics with ISIS. I'm not sure if you could change
> > all
> > of
> > > the timers, but I do not think that would work.
> > >
> > > The really strange thing is that R2 sees the adjacency as Up, whereas
R1
> > > never sees it getting passed Init. I have debugged F/R packets to
ensure
> > > that it is not an F/R map issue, and it does not appear to be.
> > >
> > > R2 is a point-to-point interface, and you cannot use a F/R map
statement
> > on
> > > this. You just use a F/r intf-dcli statement. If you notice, R1's
> > > point-to-point interface works fine with R3's physical F/R interface
> > (with
> > > frame map clns statements in their). It's certainly starting to look
> > like
> > it
> > > is not possible to get an F/R multipoint interface to tal to a
> > > point-to-point (or phyical interface). Without the f/r map statement
on
> > the
> > > physical interface of R3 I was getting errors when I did debug f/r
> > packet.
> > >
> > > Derek...
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Mark, Detrick [SMTP:mdetrick@cisco.com]
> > > > Sent: 18 June 1999 17:49
> > > > To: Derek Fage; ccielab@groupstudy.com
> > > > Subject: Re: ISIS Routing issues
> > > >
> > > > Looking at it more closely,
> > > >
> > > > I noticed that your R1 int s0.1 is a multipoint and the router on
the
> > > > other
> > > > side is R2 int s0.1 and it is point-to-point. When setting up this
> > type
> > > > of
> > > > network the serial interfaces on all sides of a p-to-m should be set
> > to
> > > > multipoint. When both sides are set this way the routing
> > characteristics
> > > > will be consistent among all participating routers. This is
probably
> > not
> > > > your problem, however.
> > > >
> > > > On router R2, I don't see the frame map clns statement.
> > > > R1(hub)/R2(spoke)/?(spoke) are point-to-multipoint. Participating
> > routers
> > > > based on the subnet of the int. It appears that there is only one
> > spoke
> > > > at
> > > > this time.
> > > >
> > > > On router R3, there is a frame map clns statement and I don't think
> > you
> > > > need
> > > > one there. R3/R1 are point-to-point FR right?
> > > >
> > > > Mark Detrick
> > > > DSL Business Unit
> > > > Cisco Systems
> > > > 2569 McCabe Way
> > > > Irvine, CA 92614
> > > > ----- Original Message -----
> > > > From: Derek Fage <DerekF@itexjsy.com>
> > > > To: 'Mark, Detrick' <mdetrick@cisco.com>; Derek Fage
> > <DerekF@itexjsy.com>;
> > > > <ccielab@groupstudy.com>
> > > > Sent: Friday, June 18, 1999 9:18 AM
> > > > Subject: RE: ISIS Routing issues
> > > >
> > > >
> > > > > If you look at the configs, I have got the map statements in, but
it
> > > > still
> > > > > does not work.
> > > > >
> > > > > Derek...
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Mark, Detrick [SMTP:mdetrick@cisco.com]
> > > > > > Sent: 18 June 1999 17:17
> > > > > > To: Derek Fage; ccielab@groupstudy.com
> > > > > > Subject: Re: ISIS Routing issues
> > > > > >
> > > > > > I have read Jeff Doyle's book and he makes a statement that
IS-IS
> > > > (really
> > > > > > CLNS) can't be done over a point-to-multipoint interface.
> > However,
> > he
> > > > is
> > > > > > not correct. What will make it work are map statements.
Instead
> > of
> > > > > > mapping
> > > > > > IP addresses, map the CLNS address to the DLCI.
> > > > > >
> > > > > > Mark Detrick
> > > > > > DSL Business Unit
> > > > > > Cisco Systems
> > > > > > 2569 McCabe Way
> > > > > > Irvine, CA 92614
> > > > > > ----- Original Message -----
> > > > > > From: Derek Fage <DerekF@itexjsy.com>
> > > > > > To: <ccielab@groupstudy.com>
> > > > > > Sent: Friday, June 18, 1999 6:58 AM
> > > > > > Subject: ISIS Routing issues
> > > > > >
> > > > > >
> > > > > > > Hi there,
> > > > > > >
> > > > > > > I'm now playing with IS-IS routing for IP in my lab
(attempting
> > to
> > > > > > replace
> > > > > > > an OSPF configuration).
> > > > > > >
> > > > > > > The links are a mixture of ethernet and serial (Frame Relay).
> > > > > > >
> > > > > > > I have no problems with ethernet links, F/R physical or
> > > > point-to-point
> > > > > > > links, but I do not seem to be able to get a link between a
F/R
> > > > > > > point-to-point link on one router to form an adjacency with an
> > F/R
> > > > > > > multipoint link on another router.
> > > > > > >
> > > > > > > On the point-to-point link, the adjacency appears to form
(show
> > clns
> > > > > > neigh
> > > > > > > displays the remote router as being Up), but on the multipoint
> > > > router
> > > > > > the
> > > > > > > clns neigh seems to stay in Init state.
> > > > > > >
> > > > > > > I cannot find anything talking about F/R issues in the Cisco
> > > > > > documentation,
> > > > > > > and just want to check that I'm not attempting to flog a dead
> > horse
> > > > > > here.
> > > > > > > Should this configuration work ?
> > > > > > >
> > > > > > > Extract from configs at end of email
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Derek...
> > > > > > >
> > > > > > > R1-multipoint-----point-to-point-R1-ethernet-----ethernet-R5
> > > > > > > |
> > > > > > > | f/r point-ro-point
> > > > > > > |
> > > > > > > |
> > > > > > > | f/r physical
> > > > > > > |
> > > > > > > R3
> > > > > > >
> > > > > > > R1
> > > > > > > clns routing
> > > > > > > int s0.1 multipoint
> > > > > > > ip address 172.16.254.1 255.255.255.0
> > > > > > > ip router isis
> > > > > > > frame map ip 172.16.254.2 102 broadcast
> > > > > > > frame map clns 102 broadcast
> > > > > > > int s0.2 point-to-point
> > > > > > > ip address 172.16.253.1 255.255.255.0
> > > > > > > frame-relay interface-dlci 104
> > > > > > > ip router isis
> > > > > > > router isis
> > > > > > > net 00.0002.1111.1111.1111.00
> > > > > > >
> > > > > > > R2
> > > > > > > clns routing
> > > > > > > int e 0
> > > > > > > ip address 172.16.5.2 255.255.255.0
> > > > > > > ip router isis
> > > > > > > int s0.1 point-to-point
> > > > > > > ip address 172.16.254.2 255.255.255.0
> > > > > > > frame-relay interface-dlci 201
> > > > > > > ip router isis
> > > > > > > router isis
> > > > > > > net 00.0002.2222.2222.2222.00
> > > > > > >
> > > > > > > R5
> > > > > > > clns routing
> > > > > > > int e 0
> > > > > > > ip address 172.16.5.5 255.255.255.0
> > > > > > > ip router isis
> > > > > > > router isis
> > > > > > > net 00.0002.5555.5555.5555.00
> > > > > > >
> > > > > > > R3
> > > > > > > clns routing
> > > > > > > int s0
> > > > > > > ip address 172.16.253.3 255.255.255.0
> > > > > > > encaps frame-relay
> > > > > > > frame-relay map ip 172.16.253.1 103 broadcast
> > > > > > > frame-relay map clns 103 broadcast
> > > > > > > ip router isis
> > > > > > > router isis
> > > > > > > net 00.0004.4444.4444.4444.00
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > >
>
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:21:39 GMT-3