[j-nsp] JNCIP questions: eBGP cast study

Harry Reynolds harry at juniper.net
Wed Sep 2 19:35:08 EDT 2009


There are many way to achieve the same goal in junos. The test is graded by result. As long as your solution works, and does not break any restrictions, then you are good to go. 

When in doubt you can ask/clarify with the proctor, but in generally the books show but one way, and certainly never meant to imply the best or only way.

Not sure what you are asking below wrt customer vs peers. For the former, the requirement is to accept *all* customer routes that originate in the two customer networks. The two customer nets are linked via some backdoor. Having both r4 and r7 accept 65010 and 65020 help improves redundancy, which may in itself be a requirement via some "ensure no single link fail isolates bla bla bla" statement.

HTHs




-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Yue Min
Sent: Wednesday, September 02, 2009 4:10 PM
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] JNCIP questions: eBGP cast study

wow, found a few things I did quite differently than the author does.
anyone interested to discuss? :)

1. "Ensure that all routers in your AS forward through r2 to reach peer prefixes when r2 is operational."
The author set LP to 101 for AS1492 routes which are recieved by r2 and reflected by RR to r1. I just simply set MED 100 on r2 and MED 200 on r1 and all peering route set LP to 200. quesion: is my solution correct?

2. cust/peer import policy
while the requirement says "Accept all customer routes that have originated in customer sites to accommodate the C1-C2 EBGP peering shown earlier in Figure 6.6." ( I feel confued here too. does that mean R4 should only receive ".* 65010"? but seems the solution in book allow R4 to receive ".* 65020" too, same on R7 ), but it doesn't say same thing for peer, so I assume R1/R2 shouldn't use as-path ".* 1492"
as inbound filter as the bood does. any thought on this?

3. export policy
biggest difference is here. what I wrote: ( r4, for example, similar on other routers )

policy-options policy-statement export-to-cust term export-internal {
    from {
        route-filter 10.0.0.0/8 exact accept;
        route-filter 192.168.0.0/22 exact accept;
        route-filter 172.16.40.0/29 exact accept;
    }
}
term export-cust {
    from community [ learned-from-peer learned-from-transit ];
    then accep
term block-all-else {
    then reject;
}

I just simple use route-filter to select route to announce to peers, and it doesn't matter the active route in my routing table is IGP route or BGP route. ( if there're not much internal routes, we use route-filter, if there're a lot, we use community to select route, which the active routes have to be bgp route or use advertise-inactive
) however, the book rely on the default bgp policy to announce bgp route out and then use a route-filter to suppress specific route and use advertise-inactive to export inactive bgp route due to protocol preference. my question: is my solution correct?


thanks for anyone interested in discussion. will post more questions later probabaly...


Min
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp


More information about the juniper-nsp mailing list