From: Brian Lodwick (xpranax@xxxxxxxxxxx)
Date: Mon Oct 15 2001 - 12:38:24 GMT-3
Actually I believe it is possible to create an adjacency with a physical
interface and a multipoint sub-interface in ISIS.
The only bad combinations are point-to-point sub-interfaces with anything
other than another point-to-point sub-interface.
ISIS over NBMA networks:
point-to-point sub-interface & multipoint sub-interface (BAD)
point-to-point sub-interface & physical (BAD)
point-to-point sub-interface & point-to-point sub-interface (GOOD)
physical & physical (GOOD)
multipoint sub-interface & multipoint sub-interface (GOOD)
multipoint sub-interface & physical (GOOD)
NOTE: below my comments are my configs showing an ISIS neighbor relationship
between Physical interface and Multipoint sub-interface over a Frame-Relay
hub-spoke topology.
Unlike OSPF, ISIS only defines 2 networks types Broadcast and
Point-to-Point. The only interface in an NBMA network considered a
Point-to-Point network type is a Point-to-Point sub-interface.
Nope you cannot manually set the network type in ISIS.
You can however manually set the Hello/Dead.
Hello timer in OSPF = isis hello-interval
Dead timer in OSPF = isis hello-multiplier
Default isis hello-multiplier is 3 x hello-interval
Here is another fun fact about ISIS. ISIS will sometimes attempt to pad
update packets to the maximum MTU size. If you do not want this action to
happen you should manually disable hello padding. If one neighbor is padding
and another is not you will run into an MTU mismatch, and the neighbor will
be considered an ES-IS peer instead of a IS-IS peer. If you are encountering
adjacency issues debug isis adj-packets and debug isis spf-events. If you
notice an error relating to MTU size mismatch show clns is-neighbor. The
output from this will most likely show one of your neighbors state as INIT
and the type is IS. Then if you show clns neighbor you will likely see the
neighbor set as an ES-IS neighbor. To aleviate this issue it is recommended
you manually set the MTU on the interface.
There is a similar issue with MTU mismatches that can be encountered when
running OSPF over a tunnel. This neighbor relationship will attempt to be
created but the MTU's can be quite different on each side since the real
physical connections may have quite different MTU sizes (ATM 4470 Eth 1500).
Fortunately we all know OSPF is a superior routing protocol to ISIS right?
Well on the new IOS there is an option in OSPF to ignore MTU mismatches:
r1(config-if)# ip ospf mtu-ignore
>>>Brian
r1 (cut from sh run)
interface Serial0
ip address 172.16.30.3 255.255.255.0
no ip directed-broadcast
ip router isis
encapsulation frame-relay
no ip mroute-cache
no fair-queue
clockrate 64000
frame-relay map clns 107 broadcast
frame-relay map ip 172.16.30.1 107 broadcast
frame-relay map ip 172.16.30.2 107 broadcast
r1#sh clns is-neighbors
System Id Interface State Type Priority Circuit Id Format
r7 Se0 Up L2 64 r7.01 Phase V
r7 (cut from sh run)
interface Serial1/0:0.2 multipoint
ip address 172.16.30.1 255.255.255.0
ip router isis
frame-relay map clns 701 broadcast
frame-relay map ip 172.16.30.2 703 broadcast
frame-relay map ip 172.16.30.3 701 broadcast
r7#sh clns is-neighbors
System Id Interface State Type Priority Circuit Id Format
r1 Se1/0:0.2 Up L2 64 r7.01 Phase V
r8 AT0/0.1 Up L2 0 00 Phase V
>From: "John Elias" <jelias_@hotmail.com>
>Reply-To: "John Elias" <jelias_@hotmail.com>
>To: CharlesNY2000@Yahoo.Com, ccielab@groupstudy.com
>Subject: Re: isis with Frame-Relay interfaces
>Date: Mon, 15 Oct 2001 09:34:34 -0400
>
> No, you can only form a neighbor with a point to point interface as far
>as isis and frame-relay is concerned.
>
>CCIE #8150
>
>
>>From: "Charles Huang" <CharlesNY2000@Yahoo.Com>
>>Reply-To: "Charles Huang" <CharlesNY2000@Yahoo.Com>
>>To: <ccielab@groupstudy.com>
>>Subject: isis with Frame-Relay interfaces
>>Date: Mon, 15 Oct 2001 01:28:16 -0400
>>
>>is it possible to form neigbor relationship with Frame-Relay Physical
>>interface & Frame-Relay Multi-Point Sub-interface ?
>>
>>Thanks
>>Charles
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 22:33:19 GMT-3