isis, l1 external route always prefer over l2 external ?!

use junos 7.2,
a router Rx has 2 routes to reach net x.x.x.x, one is L1 external, another is L2 external, by default, Rx select the L1 external route to x.x.x.x; but i use command "set protocol isis level 1 external-preference 167" to adjust the preference of L1 external route, then commit, Rx still select the L1 external route to reach x.x.x.x, why ? or is there any way to make the Rx to prefer the L2 external route?

Any advice appreciated!

Find more posts tagged with

Comments

rossonieri#1

hi,

can you post your policy config?

Aldur

I've seen this behavior too. Is the ISIS LSP's coming two different sources by chance?

Also what does the ISIS database look like? Have you tried to clear out the ISIS database? Does this have any effect?

kingcobra.guo

to rossonieri#1 / Aldur,

top:

Rx
| \
| \
R1---R2--R3

R1--R2: 1.1.1/24
R2--R3: 2.2.2/24, L1
R3--Rx: 3.3.3/24, L1
R2--Rx: 4.4.4/24, L2

R2 config:
protocols {
isis {
export direct;
interface em1.20 {
level 2 disable;
}
interface em1.40 {
level 1 disable;
}
}
}
policy-options {
policy-statement direct {
term 1 {
from {
protocol direct;
route-filter 1.1.1.0/24 exact;
}
then accept;
}
}
}

Rx config:

protocols {
isis {
level 1 external-preference 167;
interface em2.30 {
level 2 disable;
}
interface em2.40 {
level 1 disable;
}
}
}

Rx show:

gsd@cip# run show route logical-router Rx protocol isis
inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.0/24 *[IS-IS/167] 00:24:37, metric 30
> to 3.3.3.1 via em2.30
2.2.2.0/24 *[IS-IS/15] 00:24:45, metric 20
> to 3.3.3.1 via em2.30

gsd@cip# run show isis database logical-router Rx detail
IS-IS level 1 link-state database:
cip-r2.00-00 Sequence: 0x10, Checksum: 0x67ef, Lifetime: 980 secs
IS neighbor: cip-r3.02 Metric: 10
IP prefix: 1.1.1.0/24 Metric: 10 External Up
IP prefix: 2.2.2.0/24 Metric: 10 Internal Up
cip-r3.00-00 Sequence: 0x11, Checksum: 0x1787, Lifetime: 1169 secs
IS neighbor: cip-r3.02 Metric: 10
IS neighbor: cip-Rx.02 Metric: 10
IP prefix: 2.2.2.0/24 Metric: 10 Internal Up
IP prefix: 3.3.3.0/24 Metric: 10 Internal Up
cip-r3.02-00 Sequence: 0xe, Checksum: 0xa201, Lifetime: 977 secs
IS neighbor: cip-r2.00 Metric: 0
IS neighbor: cip-r3.00 Metric: 0
cip-Rx.00-00 Sequence: 0xc, Checksum: 0x7d6d, Lifetime: 574 secs
IS neighbor: cip-Rx.02 Metric: 10
IP prefix: 3.3.3.0/24 Metric: 10 Internal Up
cip-Rx.02-00 Sequence: 0x2, Checksum: 0x2b7d, Lifetime: 535 secs
IS neighbor: cip-r3.00 Metric: 0
IS neighbor: cip-Rx.00 Metric: 0
IS-IS level 2 link-state database:
cip-r2.00-00 Sequence: 0x11, Checksum: 0x7e09, Lifetime: 465 secs
IS neighbor: cip-Rx.03 Metric: 10
IP prefix: 1.1.1.0/24 Metric: 10 External Up
IP prefix: 2.2.2.0/24 Metric: 10 Internal Up
IP prefix: 3.3.3.0/24 Metric: 20 Internal Up
IP prefix: 4.4.4.0/24 Metric: 10 Internal Up
cip-Rx.00-00 Sequence: 0x11, Checksum: 0x81c, Lifetime: 594 secs
IS neighbor: cip-Rx.03 Metric: 10
IP prefix: 2.2.2.0/24 Metric: 20 Internal Up
IP prefix: 3.3.3.0/24 Metric: 10 Internal Up
IP prefix: 4.4.4.0/24 Metric: 10 Internal Up
cip-Rx.03-00 Sequence: 0x2, Checksum: 0xddcb, Lifetime: 574 secs
IS neighbor: cip-r2.00 Metric: 0
IS neighbor: cip-Rx.00 Metric: 0

I tried to use command: clear isis adjacency logical-router Rx / restart routing logical-router Rx , but it didn't take any effect

zrcheng

If we can have another choice, I think on R2 do a passive interface will make Rx happy.

Aldur

try, clear isis database logical-router Rx

Also, keep in mind that you are using virtualized olives so an error like this can be easily attributed to that. I saw some really funny behavior when I was playing with hardware olives that wasn't there when I replaced them with real routers.

kingcobra.guo

clear isis database logical-router Rx, didn't make things better;

I will try it with real routers

thanks

nick619

I would also try 'restart routing logical-router Rx' after the config change is committed. This will bounce any protocol adjacency as well.

zoidberg

I believe this is how the protocol works. In this case, when presented to the Dijkstra algorithm, the L1 should be preferred over the L2. Changing the protocol preference is not swaying this calculation as the preference is applied to results of calculation and does not affect the calculation itself. The routes that Dijkstra calculates will be sent to the route table where the preference will then be added and compared. However, Dijkstra favors the L1 route and not the L2 route, so this never becomes a battle of route protocol preference.

See these 2 RFCs details on route selection preferences:
RFC 5302 : Domain-Wide Prefix Distribution with Two-Level IS-IS
RFC 1195 : Use of OSI IS-IS for Routing in TCP/IP and Dual Environments

OSPF should exhibit the same behavior where intra-area routes are preferred over inter-area routes, even if you try to configure the preference or admin distance to the contrary.

rossonieri#1

zoidberg,

I believe this is how the protocol works. In this case, when presented to the Dijkstra algorithm, the L1 should be preferred over the L2. Changing the protocol preference is not swaying this calculation as the preference is applied to results of calculation and does not affect the calculation itself. The routes that Dijkstra calculates will be sent to the route table where the preference will then be added and compared. However, Dijkstra favors the L1 route and not the L2 route, so this never becomes a battle of route protocol preference.

thats what i've thought, but i just could not find where the reference is.
thank you for the RFCs and the explanation (a along with the OSPF), so i have better understanding now - and should have design the ISIS network more carefully then.

i was thinking why L1 external prefered over L2 external is because any L2 network will be considered as internet backbone - just like OSPF intra-area routes that injected from area 0. please correct me if i'm wrong here.

thank you

Aldur

Ahh yes, zoidberg is correct, man i should have realized that before. It's just like ospf preferring intra-area routes over inter-area routes. It doesn't matter what the hell you do to the inter-area routes, the intra-area routes are going to win everytime.

rossonieri#1

just for an OSPF refreshment,

quoted from here :
OSPF and BGP/MPLS VPNs

OSPF Route Type Attribute

The route type attribute carries the OSPF area ID and LSA type:
Type of route

Origin of route

1 - intra-area route
Type 1 LSA

2 - intra-area route
Type 2 LSA

3 - interarea summary route
Type 3 LSA

5 - external route (area ID = 0)
Type 5 LSA

7 - external route (area ID = 0)
Type 7 LSA

ok, so the type 3 will never win to both type 1 & 2.

in this OPs case, he injected a static route 1.1.1.0/24 (R2-R1) into the ISIS, so that would be an external L1 via R3 and L2 via R2 on ISIS - to Rx.

the question :
if we cant change the L2 external-preference on Rx to win over L1 - then using which way to make it possible?

i assume, from R2 can we make the L1 link to R3 with lower preference value? but, wont it be just the same? since Rx will receive the external L1 route from R3 with the same default value of 160?

i think i should lab this first, the whole previous lab was based on Rx and R2 L1 passive interface.

zoidberg

rossonieri#1 wrote: »

ok, so the type 3 will never win to both type 1 & 2.

correct. generally, type 1 > 2 > 3 > 5 > 7. it's the same principle of the most specific route. if i have a lsa 2 telling me i can reach in my 1.1.1.1 on my local broadcast segment, why would i want to listen to lsa 3 telling me to send my traffic completely out of my area. if i'm local to the destination, why send it around the world only to come back to me at the end?

rossonieri#1 wrote: »

if we cant change the L2 external-preference on Rx to win over L1 - then using which way to make it possible?

why? what is it you're trying to accomplish? all i see so far is an attempt at manually creating a nasty routing loop. maybe i'm missing something here? i have a couple ideas, but i'd like to hear your reasoning.

if you were really intent on this, i guess one avenue of attack would be conditional route redistribution. setup a policy to not redist the route into L1 unless condition X is met; such as the L2 route is missing. oh course, you quickly start running into the chicken and egg scenarios and things will likely get messy. maybe better to watch for the loopback of the L2 redistributing router.

can you explain what you're trying to accomplish and how the network is designed. perhaps it will make more sense then and a solution can be found.

rossonieri#1

hi zoidberg,

wow, this topic turned out to be a nice discussion

ok, let me put it this way :

if i have a lsa 2 telling me i can reach in my 1.1.1.1 on my local broadcast segment, why would i want to listen to lsa 3 telling me to send my traffic completely out of my area.

i was thinking of being L2 connecting *backbone* areas - all of my L2 routers should have bigger pipes, well - they should indeed.

the small picture was like this :

Rx/HQ/main data-center ---L2--- R2/Medium Branch --- <static> --- R1/backup data-center 
      |                                        |
      ----L1------ R3/small branch --L1----

Rx to R2 has 1mbps attached
Rx/R2 to R3 has 256k.
* this one, i should lab it first too

if i cant have that direct connection from Rx to R2 to replicate my DB to R1, then i should overwhelmed R3, and this condition should probably apply to other area as well (some with the same scenario).

and, actually i have the same thinking as you :

if you were really intent on this, i guess one avenue of attack would be conditional route redistribution.

basically, i should just do PBR - am i correct?

zoidberg

so the issue is routing to the datacenter networks from remote sites like R3 right? you don't want to use those sites as a transit, you want to use your L2 backbone for that. right? makes sense.

i assume you're redistributing the DC network in as a L2 route. lets start by saying you're doing that at Rx.

why put the datacenter route into L1? you could just leave it as a L2? R3 will see the attached bit from it's L2 neighbors and route traffic destined to the datacenter network via it's metrically closest attached L2 neighbor.

or, if you leak the L2 external DC route from Rx into L1 at Rx (L1/L2 border router), Rx should still see the L2 as preferred. R3 will see the route leaked in as L1, and will not see a L2 route. when R3 tries to send that route back to R2, it should have the down bit set and R2 will ignore not accept that route back from R3. this will keep your L2 backbone as the transit for the DC network, and transit DC traffic should not enter your L1 area.

zoidberg

i may need to make some corrections there. with the attached bit, i'm making the assumptions that your using more than one area. otherwise you may need to leak a default route (or other routes) into the L1 area.

correct me where i'm wrong here... i have a feeling i'm overlooking something...

zoidberg

rossonieri#1 wrote: »

if i cant have that direct connection from Rx to R2 to replicate my DB to R1, then i should overwhelmed R3, and this condition should probably apply to other area as well (some with the same scenario).

so you're looking at a failure situation where the link between Rx and R2 fails, and are worried that traffic will overwhelm R3?

Rx (L2) should not use R3 (L1) as a transit to reach R2 (L2), and vice versa. your backbone is segmented and you need to dispatch a tech to fix that asap :P

i guess the good news though, your R3 site still has connections to both datacenters, and depending on how you define your routing policies at the Rx/R2 L1/L2 routers it could use either one. you may want to look at your policy routing scenarios there. R2 shouldn't be able to talk to Rx while the L2 is discontiguous, but it should be able to talk to the backup center.

rossonieri#1

hi zoidberg,

i'm a little bit messy right now - a lot of designs and labs to do, but i've found this *sham-link* very interesting to read :
OSPF Sham-Link Support for MPLS VPN - Cisco Systems
OSPF Sham Links Overview

i might try that as well.
i'll follow up this ISIS discussion later on.

cheers