IS-IS Configuration......Its Important

Dear all,

I have configured ISIS protocol on my seven routers according to JNCIP Book Lab(page#287).I have configured every thing related to ISIS protocol but during adjacency verification, some links were fluctuating (some time up, some time goes into initialization and some time goes down).

Then I confirmed from JNCIE experts and they have asked me that point-to-point configuration is missing in your configuration.

when i configured point-to-point configuration then found No Adjacency even a single on any router out of seven routers.

one of my friend told me that I need to perform some configurations on my olive on which network adopter bridging need to changed into custom configurations.after applying this configuration then the adjacency made successful.

Is this fine to configure olive like this for ISIS proper communication.
and why we need to configure point-to-point interfaces as adjacency goes down after this configuration and when we remove it then adjacency again made successful.

please guide, why this is happening!

Find more posts tagged with

Comments

Aldur

I think this issue is more specific to virtualized olives of which I have no experience in.

Can somebody with virtualized olive experience comment on this?

In the past when I've seen people have these problems the point-to-point configuration solved the issue, why you may ask, I have no idea. This fixed something specific in how they setup their olives. With yours this definitely wasn't the problem. It's all specific to how your olives are setup, that's one problem with olives, your gonna run into odd issues like this that you would never see on a real router.

Also, I would say that as long as your ISIS neighbors are staying up and your passing routes there is no need to worry about this not working for you.

toufiq

Thanks Aldur,

Now my ISIS adjacency are up and working fine but I have made some configuration on olive.but again i have never configured the p2p configuration on ISIS speaking routers.In my JNCIP exam, is it will be requirement to configure p2p on interface or we don't need it, if adjacency up and working fine.

Regards,
Toufiq

Aldur

In the JNCIP all that matters is that the ISIS adjacency is up and functioning. You are graded off of functionality and not how you do it.

So just get those adjacencies up and running and you'll be good

Salman Aziz

toufiq wrote: »

Dear all,

I have configured ISIS protocol on my seven routers according to JNCIP Book Lab(page#287).I have configured every thing related to ISIS protocol but during adjacency verification, some links were fluctuating (some time up, some time goes into initialization and some time goes down).

Then I confirmed from JNCIE experts and they have asked me that point-to-point configuration is missing in your configuration.

when i configured point-to-point configuration then found No Adjacency even a single on any router out of seven routers.

one of my friend told me that I need to perform some configurations on my olive on which network adopter bridging need to changed into custom configurations.after applying this configuration then the adjacency made successful.

Is this fine to configure olive like this for ISIS proper communication.
and why we need to configure point-to-point interfaces as adjacency goes down after this configuration and when we remove it then adjacency again made successful.

please guide, why this is happening!

Dear Toufiq

I am facing the same problem as you did

Can you please tell me what modifications you made to make it work.

I changed the interfaces from custom specific to bridge and vice versa

But no effect.

Thanks & Regards
Salman

kronicklez

Hi Salman Aziz,

I try play with isis in olive but not face problem as you mention. Are you use a logical router in olive?

Salman Aziz

kronicklez wrote: »

Hi Salman Aziz,

I try play with isis in olive but not face problem as you mention. Are you use a logical router in olive?

Dear kronicklez

The problem is resolved now as i added the interfaces under different vmnets rather then under custom specific option.

Now neighborships are stable.

Can you please tell me how to use serial connection with vmware to connect olives.

Or can we make one olive a terminal server and access all routers by acccessing the terminal server through secure crt.

Thanks & Regards

hasan1507

Guys there is a software Virtual Serial port Driver install it and make pair of virtual serial ports equal to no of your routers in olive and map the pair of serial ports one in vmware; one for olive and one in securecrt to access the olive.

like you made one paire COM21 COM22

in olive vmware you would assign COM21 and in securecrt you will give COM22 to access that olive.

powercharme

Salman Aziz wrote: »

Dear kronicklez

The problem is resolved now as i added the interfaces under different vmnets rather then under custom specific option.

Now neighborships are stable.

Can you please tell me how to use serial connection with vmware to connect olives.

Or can we make one olive a terminal server and access all routers by acccessing the terminal server through secure crt.

Thanks & Regards

WITH VMware ,you can work it out with the mini software Named Pipe TCP Proxy.
check it on VMware Communities: Access VM Serial Console - Named Pipe ...
and you can dl it on
Named Pipe TCP Proxy Utility
or search it on Google

Salman Aziz

powercharme wrote: »

WITH VMware ,you can work it out with the mini software Named Pipe TCP Proxy.
check it on VMware Communities: Access VM Serial Console - Named Pipe ...
and you can dl it on
Named Pipe TCP Proxy Utility
or search it on Google

Thanks alot man

Between what do you think abt the policy below.
Given the following policy, what happens when the 1.1/17 route is evaluated?

[edit policy-options]
policy-statement test {
from {
route-filter 0/0 orlonger accept;
route-filter 1.1/17 upto /24 reject;
route-filter 1.1/18 exact;
}
then {
metric 6;
accept;
}
}

A. The route does not match the policy.
B. The route is accepted.
C. The route is rejected.
D. The route is accepted with a metric of 6.

please answer and explain as well, why?

awaiting ur answer.

Thanks & Regards

Salman

darry9502

Salman Aziz wrote: »

Thanks alot man

Between what do you think abt the policy below.
Given the following policy, what happens when the 1.1/17 route is evaluated?

[edit policy-options]
policy-statement test {
from {
route-filter 0/0 orlonger accept;
route-filter 1.1/17 upto /24 reject;
route-filter 1.1/18 exact;
}
then {
metric 6;
accept;
}
}

A. The route does not match the policy.
B. The route is accepted.
C. The route is rejected.
D. The route is accepted with a metric of 6.

please answer and explain as well, why?

awaiting ur answer.

Thanks & Regards

Salman

The answer is B, the route is accepted without any change in metric.

The 0/0 orlonger represent ALL routes, and the "Accept" action at the end of the route-filter simply mean this route is acceted for the policy.

You can try to configure ebgp between 2 routers. Add a static route for 1.1/17 and redistribute (export) it into the BGP. You can then verify the various condition based on your setting. In this way, you will understand the route filter better.

Oh, this is my first post in this forum. I am new here and hoping to get more valuable discussion with all of you. Cheers!

zoidberg

Welcome to the forum darry9502.

I am going to need to disagree with you on this answer though and go with C.

The route-filters are not necessarily evaluated in a sequential order, but by the most specific match. In this case, 1.1/17 will hit the route-filter 1.1/17 upto /24 reject and be rejected.

If the prefix was 5.5/16, then yes, 0/0 would catch it and the route would be immediately accepted without the prefix adjustment in the then clause.

zoidberg

Here's an often overlooked feature, test policy :

juniper> test policy test 1.1/17    

Policy test: 0 prefix accepted, 1 prefix rejected

juniper> test policy test 5.5/16    

inet.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both

5.5.0.0/16         *[Static/5] 00:05:36
                      Discard

Policy test: 1 prefix accepted, 0 prefix rejected

juniper> test policy test 1.1/18    

inet.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both

1.1.0.0/18         *[Static/5] 00:00:11
                      Discard

Policy test: 1 prefix accepted, 0 prefix rejected

juniper>

The prefix needs to be in the routing-table. Between tests I removed 1.1/17 and added 1.1/18.

zoidberg

here's a doc on using route-filters in policies.

Juniper Networks :: Technical Documentation :: Configuring Route Lists for Use in Routing Policy Match Conditions

darry9502

zoidberg wrote: »

Welcome to the forum darry9502.

I am going to need to disagree with you on this answer though and go with C.

The route-filters are not necessarily evaluated in a sequential order, but by the most specific match. In this case, 1.1/17 will hit the route-filter 1.1/17 upto /24 reject and be rejected.

If the prefix was 5.5/16, then yes, 0/0 would catch it and the route would be immediately accepted without the prefix adjustment in the then clause.

Thanks for correcting my answer, I had created 3 static route (1.1/16, 1.1/17 and 1.1/18 ). The /16 route is accepted without any metric changes, the /17 is rejected and the /18 is accepted with metric 6.

I actually got "tricked" by the term allocation as my policy is based on

edit policy-options policy-statement test
set term 1 from route-filter 0/0 orlonger accept
set term 2 from route-filter 1.1/17 upto /24 reject
set term 3 from route-filter 1.1/18 exact
set term 3 from route-filter then metric 6
set term 3 from route-filter then accept

I thought that by creating different term, i would be able to test the policy easier, but i fail to note that i had actually change the question, which results in creating the wrong answer.

Anyway, the evaluation of the "term" is FCFS (First come First Serve), unlike the route-filter which match according to the longest prefix. In order for my policy to get the same response as the first policy, i will need to insert term 3 before term 2, and insert term 2 before term 1.

zoidberg

Looks like you got it and are on the right track.

You definitely need to keep ordering in mind with different terms in a policy. First match will typically end the entire policy evaluation. You wouldn't believe how often this is overlooked. I often see cases where a less specific match denies the route, and a later term tries to modify and accept it.

Also, policy-chaining. Some people seem to love to put a deny-all term at the end of their policies, but if you do that and then do an export statement with 5 policies, that deny-all is going to block the next policies from being examined. People often think, that if one policy denies it, it will check the next policy, etc, until it finds a match. Not the case, it found a match with the deny.