2.10 - eBGP aggregate to BBs -- Announce just major subnet -- or major + loopback?

On 2.10, you need to send a aggregate to the BBs.

I've seen inconsistent behavior in this from lab to lab so I'm also asking for general advice here.

 

1) Is it necessary to annouce both your major subnet and loopback network to BB routers (for this lab, and in general)?  Or is BB reachability of loopbacks not necessary?

           1*) In context of this question, the question says "an aggregate block", not block(s), so I would assum only the majro subnet (129.x.0.0/16) and not also your loopbacks, but the solution had both advertised.

2) In general, is it necessary for loopbacks to reach the BB network?  Most ping testing examples I see do not ping from the loopbacks, and in many labs it does fail.

 

As you might guess, I only advertise 129.17.0.0/16, and I don't know if it's correct or not in a LAB scenario.

Comments

  • hello, 

    i agree with your comments , i have seen inconsistant results from all the labs.

    for myself , i would advertise both unless instructed otherwise.

     

    without breaching the nda , i would "aasume" that most of the bgp questions will be specific enough to let you know.

    i.e 

    allow the backbone AS of XX to access your network. , meaning all networks.

    allow the backbone AS of XX to access your 1.1.0.0/16 network.

     

    hth 

  • Even if it says "access your network", I would still question it.  In many cases your loopbacks might not need to be advertised/routable, and would almost never ordinarily be contacted by anyone outside your network... -- Especially if one went through the trouble to put them in a seperate aggregate subnet to begin with.

    I guess at least there's at least a proctor to ask...

  •  

    For myself , "your network" encompasses all networks within your domain , whether it is needed or not.

    you have to keep in mind that the exam question dont always reflect real-world practise, there put there to "test" your understanding of the questions as much as the understanding of the technology

    The stock answer from the proctor today is " did you read the question ?" , they dont seem to be very forthcoming with any information.

    hth

  • On the same token, some of the loopbacks in this lab weren't in the IGP, along with certain of the interfaces.  I don't know to what extent every /30 link should be reachable, and I didn't see this addressed anywhere in the solution guide, but in that end I went around and inserted a bunch of network statements in eigrp -- then redistribut eigrp at the bgp level to get everything talking to pings.

    Additionally, there's also SW3/SW4 which are routing elements, but according to the diagram and everythign else don't partipcate in a routing protocol with anybody but each other.  Those devices weren't pingable frmo the rest of the domain -- this wasn't mentioned but I assume it was expected even though they are part of my network?

     

    I am noticing that after doing 5-10 of these, the points I am loosing are falling into three categories

    30% stupid mistakes

    30% Intepretation of requirements incorrectly.

    30% Don't know how to do it/tried to do the right thing incorrectly.

     

    #1 I'm trying to address #1 through better verification methods -- and maybe spending an hour after I'm finished going bath through each question -- (these are primarily it said to use OSPF process ID 55 and I used 1 [but entire MPLS build worked fine otherwise], I put the NTP server on the wrong router #, flat out forgot one question, put "testing" ipv6 loopbacks on wrong router).

    I'm seeing improvements mainly through spending  more time re-reading and checking here than anything else.

    #2 is cases like this here -- or my other NTP on SW3/4 question -- or should I use PVC rate or clock rate for determing fragment size.  Intepretation issues.

    I really don't know how to fix these and I'm making no progress here.

    #3 is doing the right (or wrong) task but with knowledge of the right requirements -- IE not setting user/pass for login block, not knowing a mac acl didn't affect IP traffic, etc.

    These are improving over practice.

     

    #1/2 remains a challenge.  Just a little frusterated, thats all :).

Sign In or Register to comment.