Options
JNCIP EBGP Peer export policy
dwater2010
Member Posts: 33 ■■□□□□□□□□
in Juniper
All, I am bit confuse with the peer export policy in JNCIP book from page 529 to 537. It is trying to advertise 10/8 from R1/R2 to P1 but that area is NSSA with no-summary so R1/R2 will have only default route in route table and adding aggregate of 10/8 with reject on R1/R2 will cause the traffic drops. So can any one help me out to understand the situation and solution.
Comments
-
Options
Aldur
Member Posts: 1,460
Ahh yes, I remember having troubles with this as well when I was going through the IP. This is tricky for a couple of reasons but what really gets people is they configure the area as an NSSA, setup IBGP/EBGP and everything is great. Then they configure the aggregate route of 10/8 on R1/R2 and advertise that to their EBGP peers. Give it a quick once over and everything's great. Then about 1/2 hr later they notice that their IBGP sessions are down for R1/R2.
What really caused the confusion here is that the EBGP session on R1/R2 going to P1 has a default holddown timer of 90 secs. So this means if you do something that will kill the EBGP sessions, creating a 10/8 agg route, you won't see them drop for 1 1/2 minutes...
There are a couple ways to overcome this problem.
First and easiest is to create a generate 10/8 route on R1/R2 instead of an aggregate route. This solves the issue by giving the aggregate route a next hop of something else then discard. And that next hop will point back towards the core allowing your IBGP sessions to stay alive.
The next option, albeit a little more complicated provides more flexibility and I like it more
This would be to create the aggregate route more towards the center of the core, R3, R4, or R5, and then redistribute it into IBGP and then let it be carried through EBGP to your EBGP peers. The painful part of this solution comes when BGP tries to pass this routing info to R1 and R2 located in the NSSA. The route will now be hidden due to the possibility of a recursive loop forming. This problem can be overcome by changing the next hop of the route through an import policy in IBGP on R1 and R2 to a route that these routers have specific knowledge of. This could be the interface address of R3/R4 located in the NSSA.
This was definitely one of the more complicated topics in the IP book and requires a bit of explanation, as you can see
. Let me know if my explanation made sense "Bribe is such an ugly word. I prefer extortion. The X makes it sound cool."
-Bender