From: Paresh Khatri (Paresh.Khatri@aapt.com.au)
Date: Wed Dec 14 2005 - 22:03:48 GMT-3
Hi Kamrul,
As I see it, you could do one of 2 things:
1. Don't worry about advertising 1.1.1.1 via ISIS to R3. Configure an outgoing route-map on the BGP session from R2 to R3 and use the 'set ip next-hop 1.1.1.2' command .. this will achieve what you were trying to do with next-hop-self. Note that next-hop-self, when used on a route reflector, will only act on routes that the RR itself injects into BGP or which it learns via EBGP. It will not act on reflected routes.
--- OR ----
2. Use ISIS L2 to L1 route leaking on R2 via the following command: 'redistribute isis ip level-2 into level-1'. This will result in R3 getting the loopback for R1 and you will not have to stuff around with the BGP next-hop.
Hope that helps,
Paresh.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
kamrul.islam@bell.ca
Sent: Thursday, 15 December 2005 08:09 AM
To: aarumuga@hotmail.com; comserv@groupstudy.com; ccielab@groupstudy.com
Subject: RE: ISIS -over NBMA
Hi Arun,
Could you tell me what would be the best solution to resolve the
following issue in MPLS/VPN environment when running ISIS. I think the
issue is very well known and a valid issue in MPLS/VPN network.
Here is the scenario. R2 is the hub, has L2 connection to R1 and L1 to
R3 but they are in two different areas. Obviously, R3 would receive
default route plus the loopback address of R2 which is 1.1.1.2 via isis.
Enable tag switching and MBGP between the R1R2 and R2R3 where R2 is a
route reflector. When R3 receive any route from R1 through bgp, R3 sees
next hop is 1.1.1.1 NOT 1.1.1.2 but the loopback of R1 is not in his
table although he has default route. In tag switching, R3 want to see
the loopback address of 1.1.1.1 so label switching can be done.
Now question is what would be the best way to advertise R1's loopback
address to R3. I thought if we do next-hop-self in R2 it will work but
it didn't. R3 still see next-hop is R1's loopback.
Lo:1.1.1.1 lo:1.1.1.2 lo:1.1.1.3
R1---------------R2---------------R3
AS1 ibgp AS1 ibgp AS1
L2/ Area2 L2/area2 L1/area1
L1/area1
Thanks and best regards,
Kamrul.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Arun Arumuganainar
Sent: December 13, 2005 3:50 AM
To: Andrew Lissitz (alissitz); Paresh Khatri; comserv@groupstudy.com;
ccielab@groupstudy.com
Subject: Re: ISIS -over NBMA
Hi Andrew ,
Your question is about ISIS over NBMA . Hence I am changing the title of
the
thread
Pls. Note : I have done this as it will be useful for people who will be
searching the archives in the future .
Let us say logical topology looks like this
s2/0 s2/0 s2/0 s2/0
R1--------R2-------R3
DLCI : 102 203
Here R2's s2/0 is connected to R1 and R3's S2/0 with DLCI 102 and 103 .
Here
R2 is HUB and R1 and R3 are the spoke .
Cisco Recommendation : Use always the point-to-point Subinterface
whenever
you have partially meshed FR connection . If at all you wanted to use
multipoint interface you must need a Full Meshed FR connection . However
Cisco has also suggested work-around for Partially meshed scenarios as
well.
Design consideration is different for L1-Only or L2-only Subnet . Let us
discuss one by one .
L1-only Subnet
============
Here You will have to manually configure HUB router as your DIS .Choice
of
DIS can be influenced by command "isis priority " command .
Sample configuration :
**********************
On Router 2
interface ser2/0
ip router isis
Isis priority 127
***********************
Pls. note : This is similar to choosing DR in OSPF NBMA scenario .
However
in OSPF we need to take an extra precaution . i.e In addition to setting
high priority for DR( HUB router ) , you should also set Zero priority
for
all the spoke routers . This step is not needed in ISIS . This is
because
ISIS DIS election is Pre-emptive in nature .
L2-Only Subnet :-
============
DIS Election Manipulation will not work here . Instead it is advised to
configure un-numbered GRE interface and enable ISIS over it .
Sample configuration :-
*****************************
On router 2
~~~~~~~~~~~
interface Tunnel0
ip unnumbered Serial2/0
ip router isis
tunnel source Serial2/0
tunnel destination 167.1.123.1
!
interface Tunnel1
ip unnumbered Serial2/0
ip router isis
tunnel source Serial2/0
tunnel destination 167.1.123.3
!
router isis
passive-interface Serial2/0
is-type level-2-only
!
On R1 and R3
~~~~~~~~~~
interface Tunnel0
ip unnumbered Serial2/0
ip router isis
tunnel source Serial2/0
tunnel destination 167.1.123.2
!
router isis
passive-interface Serial2/0
is-type level-2-only
********************************
Design Note : ISIS do not advertise prefix that belong to un-numbered
interface . In order to advertise NBMA subnet , you must add passive
interface command for serial interface that is connected frame Relay
network
under "router isis" command .
Hope this helps .
Thanks and Regards
Arun
----- Original Message -----
From: "Andrew Lissitz (alissitz)" <alissitz@cisco.com>
To: "Arun Arumuganainar" <aarumuga@hotmail.com>; "Paresh Khatri"
<Paresh.Khatri@aapt.com.au>; <comserv@groupstudy.com>;
<ccielab@groupstudy.com>
Sent: Tuesday, December 13, 2005 11:35 AM
Subject: RE: ISIS - set-attached-bit and set-overload-bit
> Ok, I got this working once I put a different L2 area on an adjacent
> router. Thanks Arun for the tip, previously my lab did not have any
> other L2 areas and thus ISIS did not create the default router as
> expected. Once I added a different ISIS area, I now see the default
> route generated.
>
> A follow up question: How do I determine which router is the DIS
router
> on a multi-access interface? In my case I was using serial multipoint
> interfaces and realized that I needed the hub to be the DIS. Once I
> configured this on the hub router, I had complete routing tables on
all
> remote routers.
>
> Thanks Arun and Group!
>
>
>
> ________________________________
>
> From: Andrew Lissitz (alissitz)
> Sent: Monday, December 12, 2005 12:21 PM
> To: 'Arun Arumuganainar'; Paresh Khatri; comserv@groupstudy.com;
> ccielab@groupstudy.com
> Subject: RE: ISIS - set-attached-bit and set-overload-bit
>
>
> My L2 router did not have a L2 neighbor in another area. Perhaps this
> is why I could not lab this? More answers in line ... in line -->
> <Andrew>
>
>
>
> ________________________________
>
> From: Arun Arumuganainar [mailto:aarumuga@hotmail.com]
> Sent: Monday, December 12, 2005 12:08 PM
> To: Andrew Lissitz (alissitz); Paresh Khatri; comserv@groupstudy.com;
> ccielab@groupstudy.com
> Subject: Re: ISIS - set-attached-bit and set-overload-bit
>
>
> Hi Andrew ,
>
> My comments inline .
>
> Thanks and Regards
> Arun
> ----- Original Message -----
> From: "Andrew Lissitz (alissitz)" <alissitz@cisco.com
> <mailto:alissitz@cisco.com> >
> To: "Arun Arumuganainar" <aarumuga@hotmail.com
> <mailto:aarumuga@hotmail.com> >; "Paresh Khatri"
> <Paresh.Khatri@aapt.com.au <mailto:Paresh.Khatri@aapt.com.au> >;
> <comserv@groupstudy.com <mailto:comserv@groupstudy.com> >;
> <ccielab@groupstudy.com <mailto:ccielab@groupstudy.com> >
> Sent: Monday, December 12, 2005 8:52 PM
> Subject: RE: ISIS - set-attached-bit and set-overload-bit
>
>
>
> Hey Guys,
>
> Arun ... Nemeste, you rock man!
>
> I tried to use this in order to create default route on L1 routers. I
> do not have configs with me, but the L1 routers saw routes from all
> routers but no default route was in the routing table.
>
> [Arun]
>
> Could you explain me bit more . What do you mean create a
default-route
> on L1 routers ???
>
> <Andrew> - I was setting the attached bit on the L2 router and hoping
to
> see a default route on the L1 routers
>
> Actually there two methods for creating default route .
>
> Method 1 : setting the ATT bit
>
> This is done by default and no configuration is needed . But only
thing
> that is needed is to have L2 Neighbor that belongs to different area .
>
> By the way can you me provide your topology details in case your L1/L2
> router is not able to inject default route to L1 routers .
>
> <Andrew> - I had one router as core and two remotes in L1 only.
>
> Method 2 : default-information-originate command .
>
> This will work independent of your topology .But you should remember
> default-information will originate only L2-default . For generating
> L1-default you need special configuration ( route-map needs to be
> configured ) !!! Skeleton configuration is given below .
>
> ******************************************
> !
> route-map level1-default permit 10
> set level level-1
> !
> !
> Router isis
> default-information originate route-map level1-default
> !
> ******************************************
>
> Note : If both methods are used to generate the default , Method 2
will
> be preferred over Method 1 .
>
> <Andrew> - Thanks for the configs!
>
> [Arun]
>
> Here is what my thoughts are for this:
>
> You are using ISIS for IGP, you are asked to configure peer stub
router
> as L1 only. You are not allowed to use static default or default
> information commands. Can this method work for this remote router to
> receive a default route? This seems like a good method right?
>
> [Arun]
>
> "set-attached-bit" does not alter basic characteristic of L1-default
> routing . It only adds more constraints to it To generate L1-Default
by
> setting ATT bit , what you need, is the visibility of atleast one L2
> router that belongs to different area
>
> ***Hence the conclusion is ,this method will work only if your
topology
> permits***.
>
> [Arun ]
>
>
> Perhaps this is good practice for the core router? In the lab there
> will likely be some redistribution point between multiple routing
> domains. This would be good, any comments on this idea?
>
> [Arun]
>
> One Caution on Multiprotocol scenarios.
>
> Just be careful about this in Multi-protocol scenario . EIGRP is a
real
> villain here !!! Whenever you configure auto summary( default in EIGRP
)
> , then EIGRP generates a static default route to Null0 . The main
point
> of contention is that EIGRP default has got an admin distance very
much
> lower that any other routing protocol . So even though default route
is
> generated in ISIS it may not get installed Such scenarios more
> configurations are need to correct it . Some of techniques you can
> employ are as follows .
>
> 1) Manually increase the admin distance for EIGRP .
> 2) Redistribute L2 routes in to L1 . By this way you will inject more
> specific route in to L1 routing . Hence Black holing may not happen .
>
> <Andrew> - EIGRP auto-summary ... I can not think of a time to use
> this... Did you mean using the configuring a EIGRP summary on an
> interface? Also, if EIGRP has a default in the routing table, and the
> ISIS default does not get installed, it will still advertise it out to
> ISIS neighbors?
>
> [Arun ]
>
>
> -----Original Message-----
> From: Arun Arumuganainar [mailto:aarumuga@hotmail.com]
> Sent: Monday, December 12, 2005 10:13 AM
> To: Paresh Khatri; Andrew Lissitz (alissitz); comserv@groupstudy.com
> <mailto:comserv@groupstudy.com> ;
> ccielab@groupstudy.com <mailto:ccielab@groupstudy.com>
> Subject: Re: ISIS - set-attached-bit and set-overload-bit
>
> Hi Paresh ,
>
> I think to understand this feature we need some good understanding of
> Integrated ISIS !!!
>
> Let me explain :
>
> Default Behavior in ISIS
> ~~~~~~~~~~~~~~~~~~
> ISIS says that a L1L2 router should set the attached-bit in its L1 LSP
> when that router thinks it is attached to the L2 backbone. Currently
IOS
> uses a simple algorithm to determine if it is attached. This algorithm
> says if a
> L1L2 router during an SPF computation sees other area addresses, then
it
> thinks it is attached to the L2 backbone and hence it should set att
> bit.
>
> Problem with Default Behavior
> ~~~~~~~~~~~~~~~~~~~~~~
> Often this is good enough. However, in some network designs it can
> happen that L1L2 routers in two different areas get separated from the
> L2 backbone.
> Because they see each others area, they still think they are attached
to
> the
> L2 backbone. This might cause L1-only routers to send traffic for the
> backbone to the wrong L1L2 routers.
>
> Cisco Solution
> ~~~~~~~~~~~
> To solve this problem , IOS gives network administrators better
control
> over, when a L1L2 router should decide,it is attached to the L2
> backbone.
> Here Admistrator has the option of setting the area that should be
> visible in order to set the ATT bit
>
> Note : Irrespective of IP or CLNS, area address in ISIS is represented
> by CLNS address format ( We use " net " under "config-router" prompt
for
> specifying area ).
>
> Hence route-map for "set-attached-bit " should match area address( an
> CLNS address ) that has to visible in order to set the att bit .This
> command is applicable to both CLNS and IP routing
>
> By the way , command reference is right . Route map will infact refer
to
> CLNS routing table for the presence or absence of matching criteria
> FYI :
> To view clns route use "SHOW CLNS ROUTE" on the router in which ISIS
is
> configured .
>
> Hope this helps .
>
> Thanks and Regards
> Arun
> ----- Original Message -----
> From: "Paresh Khatri" <Paresh.Khatri@aapt.com.au
> <mailto:Paresh.Khatri@aapt.com.au> >
> To: "Arun Arumuganainar" <aarumuga@hotmail.com
> <mailto:aarumuga@hotmail.com> >; "Andrew Lissitz
> (alissitz)"
> <alissitz@cisco.com <mailto:alissitz@cisco.com> >;
> <comserv@groupstudy.com <mailto:comserv@groupstudy.com> >;
> <ccielab@groupstudy.com <mailto:ccielab@groupstudy.com> >
> Sent: Monday, December 12, 2005 4:09 PM
> Subject: RE: ISIS - set-attached-bit and set-overload-bit
>
>
> Actually Arun, I still think my initial post was correct...the command
> reference for this feature indicates that the route-map can only be
used
> for matching on CLNS routes, and not IP routes.
>
> Here's a quote from it:
>
> "The route map can specify one or more CLNS routes. If at least one of
> the match address route-map clauses matches a route in the L2 CLNS
> routing table, and if all other requirements for setting the
> attached-bit are met, the L1L2 router will continue to set the
> attached-bit in its L1 LSP. If the requirements are not met or no
match
> address route-map clauses match a route in the L2 CLNS routing table,
> the attached-bit will not be set."
>
> Regards,
>
> Paresh.
>
> -----Original Message-----
> From: Arun Arumuganainar [mailto:aarumuga@hotmail.com]
> Sent: Mon 12/12/2005 9:16 PM
> To: Andrew Lissitz (alissitz); Paresh Khatri; comserv@groupstudy.com
> <mailto:comserv@groupstudy.com> ;
> ccielab@groupstudy.com <mailto:ccielab@groupstudy.com>
> Cc:
> Subject: Re: ISIS - set-attached-bit and set-overload-bit Hi Andrew ,
>
> Paresh is almost correct .We do not have full flexibility for setting
> the ATT bit .
>
> But times are changing and features gets added up !!! Check this out
!!!
>
> This is one of the feature that are used to optimize L1-Routing .
After
> introduction of this feature , network admins can influence ATT bit
> setting using "ser-attached-bit Route-map " command .
>
> FYI : You should be using 12.2(4)T or Later .
>
> Pls. refer to the CCO Link
>
http://www.cisco.com/en/US/products/ps6599/products_white_paper09186a008
>
<http://www.cisco.com/en/US/products/ps6599/products_white_paper09186a00
> 8>
> 04fa
> 7a0.shtml
>
> or In case you have access Cisco Bug tracking tool . You can also
check
> out Bug ID : CSCdp64489
>
> Pls. Note : Even after this feature we can arbitarly set att bit in
IOS
> .
> Your L1/L2 router still need to have visibility to atleast one area
> other than its own !!!
>
> Thanks and Regards
> Arun
>
> ----- Original Message -----
> From: "Andrew Lissitz (alissitz)" <alissitz@cisco.com
> <mailto:alissitz@cisco.com> >
> To: "Paresh Khatri" <Paresh.Khatri@aapt.com.au
> <mailto:Paresh.Khatri@aapt.com.au> >;
> <comserv@groupstudy.com <mailto:comserv@groupstudy.com> >;
> <ccielab@groupstudy.com <mailto:ccielab@groupstudy.com> >
> Sent: Thursday, December 08, 2005 10:56 AM
> Subject: RE: ISIS - set-attached-bit and set-overload-bit
>
>
> > Paresh you rock! I am going to try this now, thanks
> >
> >
> > -----Original Message-----
> > From: Paresh Khatri [mailto:Paresh.Khatri@aapt.com.au]
> > Sent: Thursday, December 08, 2005 12:23 AM
> > To: Andrew Lissitz (alissitz); comserv@groupstudy.com
> <mailto:comserv@groupstudy.com> ;
> ccielab@groupstudy.com <mailto:ccielab@groupstudy.com>
> > Subject: RE: ISIS - set-attached-bit and set-overload-bit
> >
> > Hi Andrew,
> >
> > I don't believe that you can use the 'set-attached-bit' command when
> > using
> ISIS for routing IP; while the ATT bit is also used by IP, you can
only
> set it via this command when routing CLNS via ISIS.
> >
> > As for the second command, one possible way a question could require
> > you
> to use this is: configure your interior routers so that they do not
> advertise themselves as available for transit routing until BGP has
> converged on these routers. Or: configure your interior routers so
that
> they do advertise themselves as available for transit routing until 2
> minutes after the IGP routing process has started.
> >
> > Here's my little summary of how you can use the set-overload-bit
> command:
> >
> > set-overload-bit
> > ' immediately and unconditionally sets the overload bit
> >
> > set-overload-bit on-startup <seconds>
> > ' sets the overload bit on startup for the specified number of
seconds
> (from 5 to 86400)
> >
> > set-overload-bit on-startup <seconds> suppress interlevel ' sets the
> > overload bit on startup for the specified number of seconds
> (from 5 to 86400). Suppresses advertisement of any inter-level routes
> while the overload bit is set.
> >
> > set-overload-bit on-startup <seconds> suppress external ' sets the
> > overload bit on startup for the specified number of seconds
> (from 5 to 86400). Suppresses advertisement of any redistributed
routes
> while the overload bit is set.
> >
> > set-overload-bit on-startup <seconds> suppress interlevel external '
> > sets the overload bit on startup for the specified number of seconds
> (from 5 to 86400). Suppresses advertisement of any inter-level or
> external routes while the overload bit is set.
> >
> > set-overload-bit on-startup wait-for-bgp ' sets the overload bit on
> > startup. It's cleared on receiving a signal
> from BGP or after 10 minutes, whichever comes first.
> >
> > set-overload-bit on-startup wait-for-bgp suppress interlevel ' sets
> > the overload bit on startup. It's cleared on receiving a signal
> from BGP or after 10 minutes, whichever comes first. Suppresses
> advertisement of any inter-level routes while the overload bit is set.
> >
> > set-overload-bit on-startup wait-for-bgp suppress external ' sets
the
> > overload bit on startup. It's cleared on receiving a signal
> from BGP or after 10 minutes, whichever comes first. Suppresses
> advertisement of any redistributed routes while the overload bit is
set.
> >
> > set-overload-bit on-startup wait-for-bgp suppress interlevel
external
> > ' sets the overload bit on startup. It's cleared on receiving a
> > signal
> from BGP or after 10 minutes, whichever comes first. Suppresses
> advertisement of any inter-level or external routes while the overload
> bit is set.
> >
> > set-overload-bit suppress interlevel
> > ' immediately and unconditionally sets the overload bit. Suppresses
> advertisement of any inter-level routes while the overload bit is set.
> >
> > set-overload-bit suppress external
> > ' immediately and unconditionally sets the overload bit. Suppresses
> advertisement of any external routes while the overload bit is set.
> >
> > set-overload-bit suppress interlevel external ' immediately and
> > unconditionally sets the overload bit. Suppresses
> advertisement of any inter-level or redistributed routes while the
> overload bit is set.
> >
> > HTH,
> > Paresh.
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com <mailto:nobody@groupstudy.com>
> [mailto:nobody@groupstudy.com]On Behalf Of
> Andrew Lissitz (alissitz)
> > Sent: Thursday, 08 December 2005 03:01 PM
> > To: comserv@groupstudy.com <mailto:comserv@groupstudy.com> ;
> ccielab@groupstudy.com <mailto:ccielab@groupstudy.com>
> > Subject: ISIS - set-attached-bit and set-overload-bit
> >
> >
> > Hello group,
> >
> > I am trying to think of a scenario / question that may cause me to
> > think
> of this feature.
> >
> > pe1(config)#router isis
> > pe1(config-router)#?
> > set-attached-bit Conditionally advertise us as attached to L2
> > set-overload-bit Signal other routers not to use us in SPF
> > pe1(config-router)#
> >
> > My lab:
> >
> > R1 <---> R2 (My lab follows the 'KISS' design guide)
> >
> > Has anyone used these features and or can think of a question /
> > scenario
> that would cause me to look at this feature for the solution. I am
> really trying to think of how a question / scenario could be written.
> > Kindest regards group,
> >
> > Andrew
> >
> >
This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:51 GMT-3