JNCIP EBGP NLRI advertisements

Working on case study and got different results.
using ISIS and RR only for IBGP

Originate three NLRI advertisements to EBGP peers reflecting your 10/8 space, the OSPF router's routes, and the OSPF subnets, without altering the routing-options stanza on r3, r4, r6, and r7.

You must not use generated routes, but a single static route is permitted on both r1 and r2. Individual interface or link failures cannot disrupt the connectivity to P1.

on R5 aggregation. 172.16.40/29 is not advertised in bgp.

is this because i did aggregation on R7/R6 already and just policy on R5 to allow L1 external to L2? maybe best option is to passive ospf subnet and then do aggregation on R5?
if modify policy (static) on r5 and add term 3 with router filter 172.16.40/29 exact/accept.
That will workbut will still have to modify R6/R7 to get 172.16.40/29 advertised to ebgp peers which is restricted here.

how can i get this agg advertised in R5.

root@R5# edit policy-options policy-statement static

[edit policy-options policy-statement static]
root@R5# show
term 1 {
from {
route-filter 192.168.50.0/24 exact;
}
then accept;
}
term 2 {
from {
protocol aggregate;
route-filter 10.0.0.0/8 exact;
route-filter 172.16.40.0/29 exact;
route-filter 192.168.0.0/22 exact;
}
then accept;
}

[edit policy-options policy-statement static]
root@R5# exit

[edit]
root@R5# edit routing-options aggregate

[edit routing-options aggregate]
root@R5# show
route 10.0.2.0/23;
route 10.0.8.0/23;
route 10.0.0.0/8;
route 172.16.40.0/29;
route 192.168.0.0/22;

[edit routing-options aggregate]
root@R5# exit

[edit]
root@R5# edit protocols bgp

[edit protocols bgp]
root@R5# show
export static;
group ibgp {
type internal;
local-address 10.0.3.5;
authentication-key "$9$8yPx-wHkPfz6"; ## SECRET-DATA
cluster 2.2.2.2;
no-client-reflect;
multipath;
neighbor 10.0.9.6;
neighbor 10.0.9.7 {
hold-time 135;
}
}
group core {
type internal;
local-address 10.0.3.5;
neighbor 10.0.3.3;
neighbor 10.0.3.4;
}

[edit protocols bgp]
root@R5# exit

root@R5# run show route advertising-protocol bgp 10.0.3.3

inet.0: 73 destinations, 112 routes (73 active, 0 holddown, 2 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.0/8 Self 100 I
* 192.168.0.0/22 10.0.9.6 100 I
* 192.168.50.0/24 Self 100 I
* 192.168.60.0/24 10.0.9.6 100 I
* 192.168.70.0/24 10.0.9.7 100 I

[edit]
root@R5# run show route 172.16.40/29

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

172.16.40.0/29 *[IS-IS/171] 02:50:41, metric 15
to 10.0.8.10 via fxp2.0
> to 10.0.8.5 via fxp3.0

[edit]
root@R5# edit protocols isis

[edit protocols isis]
root@R5# show
export sum;
reference-bandwidth 500m;
lsp-lifetime 3600;
level 2 {
authentication-key "$9$Afo1uBEx7Vb2a"; ## SECRET-DATA
authentication-type simple;
}
level 1 external-preference 171;
interface fxp0.0 {
lsp-interval 3600;
level 1 disable;
level 2 {
hello-authentication-key "$9$NEVs4PfzF/t"; ## SECRET-DATA
hello-authentication-type md5;
}
}
interface fxp1.0 {
level 1 disable;
}
interface fxp2.0 {
level 2 disable;
level 1 priority 0;
}
interface fxp3.0 {
level 2 disable;
level 1 priority 0;
}
interface lo0.0 {
level 1 disable;
}

[edit protocols isis]
root@R5# exit

[edit]
root@R5# edit policy-options policy-statement sum

[edit policy-options policy-statement sum]
root@R5# show
term 2 {
from {
route-filter 10.0.8.0/23 longer;
}
to level 2;
then reject;
}
term 1 {
from {
protocol aggregate;
route-filter 10.0.2.0/23 exact;
}
to level 1;
then accept;
}
term 3 {
from {
protocol aggregate;
route-filter 10.0.8.0/23 exact;
}
to level 2;
then accept;
}
term 4 {
from {
protocol isis;
external;
}
to level 2;
then accept;
}

[edit policy-options policy-statement sum]
root@R5# exit

[edit]
root@R5#

here's option 2

[edit policy-options policy-statement static]
root@R5# show
term 1 {
from {
route-filter 192.168.50.0/24 exact;
}
then accept;
}
term 2 {
from {
protocol aggregate;
route-filter 10.0.0.0/8 exact;
route-filter 192.168.0.0/22 exact;
}
then accept;
}
term 3 {
from {
route-filter 172.16.40.0/29 exact;
}
then accept;
}

[edit policy-options policy-statement static]
root@R5# run show route advertising-protocol bgp 10.0.9.6 172.16.40

inet.0: 73 destinations, 112 routes (73 active, 0 holddown, 2 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.16.40.0/29 10.0.8.5 15 100 I

[edit policy-options policy-statement static]
root@R5#

problem

root@R6# run show route advertising-protocol bgp 172.16.0.22 172.16.40

[edit]
root@R6# run show route 172.16.40/29

inet.0: 78 destinations, 104 routes (77 active, 0 holddown, 3 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.40.0/29 *[Aggregate/130] 1d 03:16:15
Reject
172.16.40.0/30 *[Direct/0] 1d 19:22:05
> via fxp1.0
172.16.40.2/32 *[Local/0] 1d 19:22:05
Local via fxp1.0
172.16.40.4/30 *[OSPF/10] 1d 14:10:56, metric 2
> to 172.16.40.1 via fxp1.0

[edit]
root@R6#

Find more posts tagged with

Comments

Aldur

Granted it's early in the morn and I haven't got the required amount of caffeine in my system but I think what they're asking here is to create a static route on R1 and R2 pointing towards the core, R3 and R4 respectively, and have this static route be the 172.16.40/29 network. Then take these statics and put them into BGP. From there BGP will handle the rest and advertise this out of your network.

hoogen82

Too much information to lookup in morning

and I am not that happy drinking coffee either..

But I think I got what you wanted...

From looking at it when you redistribute 172.16 subnet from R6 and R7.. that is where all the trick is from... I didn't do passive interface.. For some reason when I prepared for the exam I always told myself no passive business and no static route business.. I would try to work it out with dynamic solutions only.. So coming back to the policy on R6.. It should look like

policy-statement ospf-isis {
term 1 {
from {
route-filter 192.168.0.0/22 longer;
route-filter 172.16.40.0/29 longer;
}
then accept;
}
term 2 {
from {
route-filter 0.0.0.0/0 exact;
}
then reject;
}
}

Now this route when inside ISIS will travel to other ISIS areas... So on R5 we deny it from going from L1 to L2.. Your ibgp/static policy looks okay.. But on the isis summ policy should look something like this..

policy-statement summ {
term 1 {
from {
protocol aggregate;
route-filter 10.0.2.0/23 exact;
}
to level 1;
then accept;
}
term 2 {
from {
route-filter 10.0.8.0/21 longer;
route-filter 172.16.40.0/29 longer;
}
to level 2;
then reject;
}
term 3 {
from {
protocol aggregate;
route-filter 10.0.8.0/21 exact;
route-filter 192.168.0.0/22 exact;
route-filter 172.16.40.0/29 exact;
}
to level 2;
then accept;
}
}
}

This should solve your problem... since the IBGP policy will advertise this route...

policy-statement ibgp {
term 1 {
from {
protocol static;
route-filter 192.168.50.0/24 exact;
}
then accept;
}
term 2 {
from {
protocol aggregate;
route-filter 10.0.0.0/8 exact;
route-filter 192.168.0.0/22 exact;
route-filter 172.16.40.0/29 exact;
}
then accept;
}
}

Cheers,
Hoogen

densma

thanks Hoogen n Aldur
yeah. i did my ISIS solution different from the book that why my EBGP advertisement got screwed.

policy-statement ospf-isis {
term 1 {
from {
route-filter 192.168.0.0/22 longer;
route-filter 172.16.40.0/29 longer;
}
then accept;
}

ospf-isis policy on r6/r7 take care of it without using passive.

Aldur

yes, it was to early to read that much info... I misread the question. Thought you needed to advertise the aggregate of the ospf routes 172.25.40/29 exactly. So yea, looks like your understanding is good now.

densma

another questions on NLRI advertisements to EBGP peers. without any restriction where is the best place to do the agg advertisment to EBGP peers? export map on each on EBGP peers or on one core router?. if advertised on core ibgp router, default bgp export policy will automaticaly advetise to EBGP peers. just like in case study, some might require special tweak to work especially with STUB/NSSA/LEVEL1 area peering with EBGP.

the case study had restriction which make R5 best option to advertise the OSPF and internal agg into bgp.
just wondering what's the best approach
thks

Aldur

Yup, I have to agree that with no restrictions R5 makes the best candidate for the export. Reason being is that R5 should have all of the routing knowledge since it's in area 0 or is a level 2 router, minus any advertisement suppression that you're doing inbetween areas/levels.

As a rule of thumb I try to put the export of the aggregate as close to the origination of the contributing routes as possible. So if it's a aggregate that represents your internal network space then the router that is in the core the most would be my choice.

densma

thanks

.

Aldur wrote: »

Yup, I have to agree that with no restrictions R5 makes the best candidate for the export. Reason being is that R5 should have all of the routing knowledge since it's in area 0 or is a level 2 router, minus any advertisement suppression that you're doing inbetween areas/levels.

As a rule of thumb I try to put the export of the aggregate as close to the origination of the contributing routes as possible. So if it's a aggregate that represents your internal network space then the router that is in the core the most would be my choice.