IS-IS hell

cisco_trooper

ok.

I've configured IS as follows

LEVEL2 only across a Frame Relay cloud. Connectivity within Level2 is fine.

LEVEL1 at all the "edge" routers. Connectivity within Level1 is fine.

Connectivity from Level1 across the Frame Relay cloud is FUBAR.

I was under the impression that routers totally in level one would have a default route into LEVEL2, to provide connectivity to the rest of the network, but this does not seem to be the case. This should have been similar to OSPF totally stubby areas. Do I have to tell it to advertise a default route somehow?? Anybody??

networker050184

Do you have a level 1/2 router set up to connect your level 1 and level 2 routers?

aueddonline

a level 1 router will route all inter area packets to it's nearest level 1-2 router.

A router is totally in 1 area but if level 1 adjacencies can't be made between routers in different areas so your level 1-2 router will have to be in the same area as all your level-1's.

To configure the level 1-2 router you need to configure the interfaces to send either L1 LSPs or L2 LSPs

L1

---

L1-L2

---

L2

networker050184

Cisco routers are L1/L2 routers by default. Think of the L1/L2 routers like an ABR. Think of L2 routers like backbone routers with all interfaces in area 0.

cisco_trooper

Router A, which has connectivity to the frame-relay cloud.
interface Loopback0
ip address 10.100.100.0 255.255.255.255
ip router isis
isis circuit-type level-2-only
!
interface FastEthernet1/0
ip address 10.0.13.1 255.255.255.252
ip router isis
duplex auto
speed auto
isis circuit-type level-1
!
interface Serial3/0
no ip address
encapsulation frame-relay
serial restart-delay 0
!
interface Serial3/0.105 point-to-point
ip unnumbered Loopback0
ip router isis
snmp trap link-status
isis circuit-type level-2-only
frame-relay interface-dlci 501
!
interface Serial3/0.2006 multipoint
ip address 192.168.126.1 255.255.255.248
ip router isis
snmp trap link-status
isis circuit-type level-2-only
frame-relay map clns 610 broadcast
frame-relay map ip 192.168.126.6 610
!
router isis
net 49.0001.0000.0000.000a.00
summary-address 10.0.0.0 255.255.0.0
summary-address 10.100.100.0 255.255.255.252
!
Router C, which is a Level-1 router with connectivity to Router A
interface Loopback0
ip address 10.100.100.2 255.255.255.255
ip router isis
!
interface FastEthernet1/0
ip address 10.0.13.2 255.255.255.252
ip router isis
duplex auto
speed auto
!
router isis
net 49.0001.0000.0000.000c.00
is-type level-1
!

With this config Router A is as Level1-2 router with interfaces in specific levels; perhaps that is the problem. Router C obviously is entirely in Level1.

aueddonline

you may need to configure ' is-type level-1-2' under router A's routing process

cisco_trooper

I'm fixing to explode. Router A is Level-1-2 by default, but I went ahead and entered the command anyway, to no avail.....

Something very stupid is missing.....I will prevail IS-IS, you hear me!!!

aueddonline

what IOS are you running.

the level-1-2 router will set the ATT bit in it's LSPs to the level 1 router, this is how the level 1 routers know how to reach other area, the ATT bit is a clns service so you might have to enable 'clns routing' although is your running a newish IOS it should set the ATT bit by default so try checking the database on the level 1 routers and see if the level-1-2 router is sending an LSP with the attached bit set

mikej412

http://www.cisco.com/warp/public/97/isis-frint.html

cisco_trooper

aueddonline wrote:

what IOS are you running.

the level-1-2 router will set the ATT bit in it's LSPs to the level 1 router, this is how the level 1 routers know how to reach other area, the ATT bit is a clns service so you might have to enable 'clns routing' although is your running a newish IOS it should set the ATT bit by default so try checking the database on the level 1 routers and see if the level-1-2 router is sending an LSP with the attached bit set

I know, that is what is **** me off. The ATT bit is not getting set. This is 12.4.18 Enterprise so I'd be surprised to find out the ATT bit doesn't work. I've also enabled clns router isis on the Level 1 interfaces. The routers are now CLNS neighbors shown in sho clns neigh

aueddonline

well that's me fresh out of ideas, are you suppose to be using a multipoint sub interface ? I know it's recommended design with ISIS to use point-to-point subinterface even ona full mesh?


for the ATT bit you could use the 'default-information originate' command configured under the routing process, still you may have already tried that

that's all I got

cisco_trooper

On the frame-relay I have one set of interfaces for point-to-point and I have another set for multipoint. I want to do the configuration both ways, even though point-to-point is more straightforward, and the recommended way of doing it. That is why I have my own frame-relay switch configured.

Anyway I'm blowing this config away and trying again...I will post my findings if I ever figure out what I screwed up...

Thanks for all the help!

cisco_trooper

It's amazing how clear things become when you walk away from them for a while.

Here is the diagnosis.

Here is what I had:
RTR_C

---

RTR_A

---

Other Frame Relay Routers
L1

---

L1-L2

---

L1-L2
Area 1

---

Area 0

---

Area 0

I had also tried
RTR_C

---

RTR_A

---

Other Frame Relay Routers
L1

---

L1-L2

---

L1-L2
Area 0

---

Area 0

---

Area 0

What worked
RTR_C

---

RTR_A

---

Other Frame Relay Routers
L1

---

L1-L2

---

L1-L2
Area 0

---

Area 0

---

Area 1

Basically I was treating the Levels as areas, thinking RTR_A, as a L1L2 router, would act similar to an ABR and give me a default route. What I failed to realize, initially, is that these two routers weren't actually in the same area, causing my initial frustration. I then placed RTR_C into Area 0 with RTR_A, expecting different results, but at that point there were no other areas in the network, and so no need for a default route. This is when the light went on. The L1 and L1L2 routers need to be in the same area, and there has to be another area within the network to get the default route on the L1 router.

cisco_trooper

Bump!!

Here we go again ISIS. I'm reading through the self-study guide right now and so far everything clicks. The lights are going on, things are coming back to me, and I am feeling good so far. I've got my frame-relay switch configured for both point-to-point and multipoint scenarios, as I did way back in the day when I originally studied this material. The 8 routers in this topology have their basic configurations. After I am done reading this material over we will see what curves my lab throw me. Having been through all this material already I am hoping to have this topic buried by Sunday evening as I won't be studying tomorrow due to Metallica's arrival.

cisco_trooper

Alright, this is NOT the first time I have run into this with ISIS. How the hell do you implement route filtering with this protocol? With any other routing protocol you can use distribution lists, route-maps, or both. With this protocol I can't figure out how to do this. Not right now, and not in the past, and frankly I'm about to come unglued and go smooth off on this sucker...

cisco_trooper

Come on.....I hope to christ I'm not the only one who has actually tried this. I KNOW I'm not the only one. Anyone have any luck doing this???

tech-airman

cisco_trooper wrote:

Alright, this is NOT the first time I have run into this with ISIS. How the hell do you implement route filtering with this protocol? With any other routing protocol you can use distribution lists, route-maps, or both. With this protocol I can't figure out how to do this. Not right now, and not in the past, and frankly I'm about to come unglued and go smooth off on this sucker...

cisco_trooper,

Route filtering between ISIS and what other routing protocol?

kpjungle

cisco_trooper wrote:

Come on.....I hope to christ I'm not the only one who has actually tried this. I KNOW I'm not the only one. Anyone have any luck doing this???

You can still use route-maps when redistributing into/out of ISIS. I think its only distribute lists thats not supported on ISIS.

cisco_trooper

Yeah I know, but I'm not redistributing. I just want to filter certain routes between different L2 routers in different areas....

cisco_trooper

OK. So I have come up with absolutely nothing on this.... How on earth do you maintain control of your routing table with multiple ingress and egress points with ISIS? I would hate to bring in a second routing protocol just so I can do redistribution JUST so I can exercise more control of the routing table. What a crock this implementation is.... Major flaw in ISIS. No wonder it didn't catch on...

Anyway, I have seen no reference to this in any of the NP or even Routing TCP/IP Volumes I or II for ISIS, so I will just sweep it under the rug (for now ) and move on to something else and get the test knocked out.

tech-airman

cisco_trooper wrote:

OK. So I have come up with absolutely nothing on this.... How on earth do you maintain control of your routing table with multiple ingress and egress points with ISIS? I would hate to bring in a second routing protocol just so I can do redistribution JUST so I can exercise more control of the routing table. What a crock this implementation is.... Major flaw in ISIS. No wonder it didn't catch on...

Anyway, I have seen no reference to this in any of the NP or even Routing TCP/IP Volumes I or II for ISIS, so I will just sweep it under the rug (for now ) and move on to something else and get the test knocked out.

cisco_trooper,

Why are you trying to "...maintain control of your routing table with multiple ingress and egress points with ISIS?"

cisco_trooper

Just labbing anything I can come up with man. In this case there is a certain Level-2 ISIS device that I do not want to receive certain routes from another Level-2 ISIS device. I can do this with ease with any other routing protocol - that being the biggest reason - why not?

tech-airman

cisco_trooper wrote:

Just labbing anything I can come up with man. In this case there is a certain Level-2 ISIS device that I do not want to receive certain routes from another Level-2 ISIS device. I can do this with ease with any other routing protocol - that being the biggest reason - why not?

cisco_trooper,

What kind of routing occurs between two Level-2 ISIS routers?

cisco_trooper

tech-airman wrote:

cisco_trooper wrote:

Just labbing anything I can come up with man. In this case there is a certain Level-2 ISIS device that I do not want to receive certain routes from another Level-2 ISIS device. I can do this with ease with any other routing protocol - that being the biggest reason - why not?

cisco_trooper,

What kind of routing occurs between two Level-2 ISIS routers?

Not sure exactly what you are asking, but I do understand that Level-2 is the backbone in ISIS and it naturally has all the Level-1 and Level-2 Routes from the different areas, I am fine with that. What I am NOT fine with is the fact that every other routing protocol, whether link state, distance vector, internal or external. Whatever the protocol they all have a method for filtering routes from the routing table.

This is possible with other hierarchical routing protocols such as OSPF with area 0. So, my question is not so much, "Why would I want to?," as it is, "Why the heck can't I?" No network is ever the same so there will always be a network that needs an exception, which is probably why you can do this with ease in any other routing protocol.

One thought I had was that the underlying mechanisms for ISIS are definitely different from other routing protocols in that it does not ride on IP or any other layer 3 protocol for that matter, which is why I would assume you can't use ACLs and distribution lists to filter routing information.

If you can implement route-filtering in ISIS through filtering through CLNS I'm fine with that, I just can't for the life of me figure out how to do it. If you can't filter routing information in ISIS, I'm not "fine" with that, but if that is the way it is, that is the way it is and I'll just have to deal with it. Whichever the case, I'm really just in search of a definitive answer other than my mere speculation....

Turgon

Level 2 is your backbone with intra area routes. Sounds like you have a couple of level 2's there and multiple IS-IS domains. Perhaps try redistributing between them with the use of a route map to filter. Alternatively you might try playing with the distance command under the IS-IS process and a route map to change admin distance for certain routes or even poison them with an AD of 255.

distribute list command was on and off for different IOS versions for IS-IS but off these days so far as I know. distribute list would screw around with the function of LSDBs within an area anyhow.

tech-airman

cisco_trooper wrote:

tech-airman wrote:

cisco_trooper wrote:

Just labbing anything I can come up with man. In this case there is a certain Level-2 ISIS device that I do not want to receive certain routes from another Level-2 ISIS device. I can do this with ease with any other routing protocol - that being the biggest reason - why not?

cisco_trooper,

What kind of routing occurs between two Level-2 ISIS routers?

Not sure exactly what you are asking, but I do understand that Level-2 is the backbone in ISIS and it naturally has all the Level-1 and Level-2 Routes from the different areas, I am fine with that. What I am NOT fine with is the fact that every other routing protocol, whether link state, distance vector, internal or external. Whatever the protocol they all have a method for filtering routes from the routing table.

What network layer addressing does Integrated IS-IS use for routing decisions for a L2 router?

cisco_trooper wrote:

This is possible with other hierarchical routing protocols such as OSPF with area 0. So, my question is not so much, "Why would I want to?," as it is, "Why the heck can't I?" No network is ever the same so there will always be a network that needs an exception, which is probably why you can do this with ease in any other routing protocol.

What exception do you imagine would necessitate route filtering?

cisco_trooper wrote:

One thought I had was that the underlying mechanisms for ISIS are definitely different from other routing protocols in that it does not ride on IP or any other layer 3 protocol for that matter, which is why I would assume you can't use ACLs and distribution lists to filter routing information.

The answer to the question in my previous post as well as the first question in this post should give you a clue towards the answer to your first sentence in this paragraph. What kind of addressing was used in the original version of IS-IS prior to Integrated IS-IS?

cisco_trooper wrote:

If you can implement route-filtering in ISIS through filtering through CLNS I'm fine with that, I just can't for the life of me figure out how to do it. If you can't filter routing information in ISIS, I'm not "fine" with that, but if that is the way it is, that is the way it is and I'll just have to deal with it. Whichever the case, I'm really just in search of a definitive answer other than my mere speculation....

Based on my studies towards the 640-801 BSCI exam, until you get to the redistribution section, you have to understand each routing protocol independent of each other. Yes, Integrated IS-IS shares some similarities with OSPF but you have to understand that it's a different routing protocol or else it would be called OSPF-ISIS or something like that. Instead of focussing how to filter routes, how about wondering how are routes shared in the first place? Then maybe it would explain how you could "interfere" with the route sharing process which is basically what you are doing with route filtering. Unfortunately, this falls under book/material studying and NOT expecting the IOS to just tell you the answer.

cisco_trooper

tech-airman wrote:

What network layer addressing does Integrated IS-IS use for routing decisions for a L2 router?

Pretty sure I mentioned CLNP already in not so many words, unless I'm just WAY OFF, which is entirely possible being that I haven't looked at this crap since March.

tech-airman wrote:

What exception do you imagine would necessitate route filtering?

There's a ton of reasons....To aid in securing a certain portion of the network from the rest....To prevent route feedback where multiple points of redistribution exist....Just because I don't feel like looking at a route in a lab....To find ways to break stuff....to name a couple but I'm sure there are more.

tech-airman wrote:

Based on my studies towards the 640-801 BSCI exam, until you get to the redistribution section, you have to understand each routing protocol independent of each other.

This would be obvious...let's not forget I am reviewing material from 6 months ago..and I'm not reviewing redistribution yet, I am reviewing ISIS...not finding the expected distribute-list option set me off on a tangent that bothers me, but seeing as how I have not seen it in either the CCNP Exam Guide OR Routing TCP/IP Volume I I have jotted it down as something to come back to after I kick this test in the nads.

tech-airman wrote:

Yes, Integrated IS-IS shares some similarities with OSPF but you have to understand that it's a different routing protocol or else it would be called OSPF-ISIS or something like that.

Pretty sure everyone one would agree ISIS is a different beast...

tech-airman wrote:

Instead of focussing how to filter routes, how about wondering how are routes shared in the first place? Then maybe it would explain how you could "interfere" with the route sharing process which is basically what you are doing with route filtering. Unfortunately, this falls under book/material studying and NOT expecting the IOS to just tell you the answer.

Pretty sure that's why I made the post. I brought this same topic up months ago when I started learning ISIS and redistribution before I got side tracked by a new job.......and I hope you are not insinuating that I expect the IOS to give me the answers, I go through this crap in as much detail as anyone and find the CCNP books to be pretty disappointing in their depth, but hey, if you think I'm lazy because I don't know some minute detail not covered even in a CCIE Professional Development book I guess that's up to you. If I were lazy the CCNP books would be enough and this question wouldn't be asked.

cisco_trooper

Turgon wrote:

Level 2 is your backbone with intra area routes. Sounds like you have a couple of level 2's there and multiple IS-IS domains. Perhaps try redistributing between them with the use of a route map to filter. Alternatively you might try playing with the distance command under the IS-IS process and a route map to change admin distance for certain routes or even poison them with an AD of 255.

distribute list command was on and off for different IOS versions for IS-IS but off these days so far as I know. distribute list would screw around with the function of LSDBs within an area anyhow.

Thanks Turgon. I actually did get this working with distance manipulation as you have stated here which prevents incoming routes from being placed in the routing table. What I now am trying to do is prevent certain routes even from being advertised out into the Level 2 backbone, so that I don't have to trust the guy that administers the remote router to get the job done. As far as redistribution I haven't found a way to redistribute between two ISIS areas that are within the same domain. All that is available in the way of redistribution is the obvious "connected", redistributing to and from different routing protocols, or between ISIS levels. Anyway, thanks for the input. I'll probably come back to this in a couple weeks after I knock this test out.

Mrock4

cisco_trooper wrote:

tech-airman wrote:

What exception do you imagine would necessitate route filtering?

....Just because I don't feel like looking at a route in a lab....To find ways to break stuff....

Spoken like a true future CCIE candidate ...I love out-of-the-box thinking like this..

I've enjoyed following this thread. It's always good to learn from others experiences.