jncip-ospf case study Question

Dears ,

when i shutdown R2 , the R4 can`t ping R1 lo0 10.0.6.1 because it can show this route as 10.0.4/22 and this cause Ibgp session between r4&r1 become down

note: when i removed area-arange 10.0.4/22 from R3 , the problem solved but this command is the requirement ....any other solution ?????????

root@r2# show | compare
[edit interfaces em3]
! inactive: unit 12 { ... }
! inactive: unit 23 { ... }
! inactive: unit 24 { ... }

root@r4> show route 10.0.6.1

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

10.0.4.0/22 *[OSPF/10] 00:03:42, metric 16777215
Discard

Thanks

Geme

Find more posts tagged with

Comments

hoogen82

Hmm... which case study is this.. You mention OSPF and then go on to say IBGP??

I don't think there is way out of this.. because of the way the topology is designed.. Is this a requirement to shut down R1?

Been a long time since I did the case study..

gemesat

i will clear my question >>

problem description :

1- i have finished the configuration of the jncip lab via olive and after that i started in troubleshooting the advertising of the BGP route, for that i made R2 down to verify the bgp route for peer 1 will be advertised through R1 but ....

2- this routes for P1 isn`t advertised due to the next-hop (unreachable )
3- the next hop unreachable because R4 can`t reach R1 lo0 (10.0.6.1) via IGP (ospf) and R4 see it as area 0 summarized route (LSA 3 10.0.4/22 )

Note: in normal status (R2 up) ,,,,R4 can reach R1 lo0 Via ospf through R2...

root@r2# show | compare
[edit interfaces em3]
! inactive: unit 12 { ... }
! inactive: unit 23 { ... }
! inactive: unit 24 { ... }

root@r4> show route 10.0.6.1

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

10.0.4.0/22 *[OSPF/10] 00:03:42, metric 16777215
Discard

i wish my update is clear .....

and i `m looking forward to your reply

thanks

ivanov.ivan

Hi,

Yes, you are right!

This discard summary route is automatically inserted because of the 'area-range'

There is one more problem when the R4 link to area 0.0.0.1 fails, the summary is not advertise any more to the backbone area. This can be fixed if the router-id of R3 is higher than router-id of R4. But I am not sure if this will fix the first problem, you can try and share the result.

This all is because R4 has only one link in area 0.0.0.1!

HTH

Ivan,

ivanov.ivan

In fact this solution will fix also the first problem that you have, because the summ route from R3 will have better metric than the infinite metric of the discard route.

So you will have IBGP peering established via R3 in that case.

HTH

Ivan,

gemesat

First of all, thanks for your reply and i have a good newsss (I solved the problem

)

first : the reason of the problem >>> when i turned R2 off , the interface between R2&R4 isn`t gone down (dueto olive mechanism

) for that the OSPF database netsummary isn`t changed,, for that R4 doesn`t lidten to the updates from R3

root@r4> show ospf database netsummary

OSPF link state database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Summary 10.0.4.0 10.0.3.3 0x80000018 102 0x22 0x3acd 28
Summary *10.0.4.0 10.0.3.4 0x80000008 107 0x22 0x40d8 28
Summary 10.0.8.0 10.0.3.5 0x80000013 1701 0x22 0xed1e 28
Summary 172.16.40.0 10.0.3.5 0x8000000f 1849 0x22 0x8ab2 28

Second: the solution >>> after i deactivate the interface between R2&R4 from R4 side ,the problem has been solved and R4 start in listening from R3 :

root@r4> show ospf database netsummary

OSPF link state database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Summary 10.0.4.0 10.0.3.3 0x80000018 298 0x22 0x3acd 28
Summary 10.0.8.0 10.0.3.5 0x80000013 1897 0x22 0xed1e 28
Summary 172.16.40.0 10.0.3.5 0x8000000f 2045 0x22 0x8ab2 28

ivanov.ivan

Hm,

You are right! I also hit Olive related issue. I test it again and it works how you describe it.

I think that this is the right behavior of Junos.

God job!