+ Reply to Thread
Page 2 of 8 First 12 3456 ... Last
Results 26 to 50 of 179
  1. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #26
    Exam: 642-902 Implementing Cisco IP Routing - English - (ENU)
    Candidate: .-
    Candidate ID: -
    Registration ID: -
    Date: 02 December 2013
    Time: * 11:00 AM
    Appointment Length: 170 Minutes


    Accommodations You have been approved for the following accommodations:
    Accommodation Time Extension (Minutes) *
    Automatic English Time Extension 30

    jelly?


    It was significantly cheaper than the CCNA (€182.5 vs. €286.5) which was a very pleasant surprise.
    Last edited by fredrikjj; 10-05-2013 at 12:30 PM.
    Reply With Quote Quote  

  2. SS -->
  3. ...loading... gorebrush's Avatar
    Join Date
    Apr 2005
    Location
    UK
    Posts
    2,728

    Certifications
    CCIE:R&S, CCNP:R&S, CCNA:S, MCSE, MCSA:M, MCTSx2
    #27
    I assume that the was the combined (802) CCNA cost you are comparing? Yes, it is more expensive as it is effectively two exams in one.
    Reply With Quote Quote  

  4. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #28
    Quote Originally Posted by gorebrush View Post
    I assume that the was the combined (802) CCNA cost you are comparing? Yes, it is more expensive as it is effectively two exams in one.
    Indeed it was.
    Reply With Quote Quote  

  5. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #29
    Day 32

    Put in my daily 5-6 hours. Mostly worked on redistribution. Towards the end of the day I started looking at OSPF because while I can configure it just fine, I'm fairly weak on the details. Btw, can you use the ip ospf x area y interface command on the exam?
    Last edited by fredrikjj; 10-06-2013 at 11:05 AM.
    Reply With Quote Quote  

  6. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #30
    Day 33

    My main objective was to determine what my weak areas (no pun intended!) were in OSPF.
    The first 5 hours or so I spent reading most of the FLG chapter, taking notes whenever I felt that it was warranted, and skimming sections that I knew that I knew. These are the things that I identified as more difficult:

    OSPF packet types
    The adjacency states (init,exstart,exchange etc..)
    the network types
    the LSA types
    special area types

    I created 10 pages of handwritten notes on these topics. I'm a bit confused about the network types. There are 5 if we include the two cisco ones, and I've put them in three categories:

    1. point-to-point

    2. broadcast and point-to-multipoint
    Both of these work over multicast capable networks, but broadcast selects DR/BDR while point-to-multi doesn't. I get that in a hub-and-spoke topology, you need to either use multipoint, or, set priority 0 on the spokes to force the hub to be the DR if you use broadcast. But, beyond that, I don't get why you would use one over the other.

    3. non-broadcast and point-to-multipoint non-broadcast
    I have the same kind of questions about these two. On the surface they seem to offer roughly the same things, but the multipoint one doesn't use a DR. Both require static neighbors.

    I took a one hour break at this point to get some fresh air. I mainly rode around on my bike, listening to Prince (Purple Rain is an all time classic!).

    I read cisco's "OSPF Design Guide", a 50 page document that's probably kind of old, but I had it printed so why not. When I was done with the Design Guide I didn't want to do more reading so I turned to the labs in the Cisco SLM. I decided to just skip the first 4 because they seemed easy

    Here are my notes. I felt fairly confident doing these but it's possible that there are mistakes (google ccnp route slm if you want to check out the topologies).

    OSPF Lab 5 "Challenge Lab"

    Configuration Requirements
    1. Configure the interfaces in the diagram with the IP addresses shown.
    2. Configure the bandwidth to reflect the actual bandwidth of all serial links.
    3. Configure OSPF with interfaces in the areas shown in the diagram.
    4. Configure R2 to summarize area 20 with the most specific mask possible.
    R2(config-rtr)#area 20 range 172.16.2.0 255.255.255.128
    5. Make the link between R1 and R2 have the OSPF network type of broadcast, with R1 as the DR.
    R2(config-if)#ip ospf network broadcast
    #ip ospf priority lower than R1, or priority 0 to make inelgible.
    6. Configure R1 to always originate a default route.
    R1(config-rtr)#default-information originate always. always keyword creates a default route even if one isn't already in the routing table? drawback of this is that you might force traffic to a router that doesn't have a way out of the AS.
    7. Modify the link between R2 and R3 to have hello timers and dead timers that are double the default
    values.
    default on point-to-point: hello 10 dead 40
    interface
    ip ospf hello-intervall 20
    ip ospf dead-intervall 80
    8. Make the link between R2 and R3 have a cost of 500.
    R2(config-if)#ip ospf cost 500
    Only needed on one side of the link?
    Should probably actually read up on how link costs work, if you need to set them on both sides or if the higher one decides.
    9. Configure area 34 to be a totally stubby area.
    R3(config-rtr)#area 34 stub no-summary
    R4(config-rtr)#area 34 stub
    10. Use MD5 authentication with the keyword “cisco” over the link between R3 and R4.
    R3(config-if)#ip ospf authentication message-digest
    #ip ospf message-digest key 1 md5 cisco
    R4(config-if)#ip ospf authentication message-digest
    #ip ospf message-digest key 1 md5 cisco
    11. Figure out the hidden issue in the topology that you need to address to have full connectivity.
    Virtual link needed to connect area 34 to area 0
    R3(config-rtr)#area 23 virtual-link 0.0.0.2 (R2's router-id)
    R2(config-rtr)#area 23 virtual-link 0.0.0.3
    authentication message-digest message-digest-key X md5 password can also be added on the same line.
    12. Run a Tcl script on all routers to verify that there is connectivity between the IP addresses in the topology.
    I'm too lazy to write that script, but a few strategically placed pings tells me that everything is in order.

    OSPF Lab 6, Troubleshooting Lab

    My first step will be to verify basic IP reachability.
    Using show ip int brief to compare the addresses with the topology map, and using ping.
    Everything seems reachable within their own segments.
    R1
    Looking at the OSPF configuration on R1, they've used an incorrect network statement for its serial interface. This is why you use the ip ospf process-id area interface command. Fixing this established the R1-R2 link.
    R2
    network type is nonbroadcast on the interface to R3. Adding the neighbor 172.16.23.3 command to the router process.
    R3
    mirror of R2.
    The virtual link is potentially faulty. checking it.
    It turns out I was right. They've used the wrong router-id on R4's virtual link statement. The fact that they haven't configured explicit router ids that make more sense than the loopbacks makes it harder to troubleshoot. Virtual link now works. Virtual links should show up in show ip ospf neighbor.

    OSPF Lab 7, OSPF Case Study

    I'm too tired to actually load GNS3 so I'm just going to write commands in Notepad.
    1. Use the addressing scheme shown in the diagram.
    2. Configure OSPF with the networks shown in the diagram.
    3. Configure the OSPF backbone area to be on Loopback0 on HQ.
    int lo0
    ip ospf 1 area 0
    4. Configure the Frame Relay subnets as point-to-point subinterfaces, with the link between HQ and
    East in area 100, and the link between HQ and West in area 300.
    int s0/0/1
    encap frame-relay - the encapsulation on the physical interface, right?
    int s0/0/1.102 point
    ip add 10.1.1.1 255.255.255.252
    frame-relay interface-dlci 102
    ip ospf 1 area 100
    int s0/0/1.103 point
    ip add 10.1.1.5 255.255.255.252
    frame-relay interface-dlci 103
    ip ospf 1 area 300
    No need to turn off inverse arp because it's off by default on point-to-point subinterfaces, I think
    5. Configure area 300 as an NSSA.
    R1(config-rtr)#area 300 nssa
    R4(config-rtr)#area 300 nssa
    Routers must agree on the area type flag or they can't form relationships.
    6. Configure the router East loopback interfaces to be in area 200. Summarize this area with the most
    efficient summary.
    R2(config-rtr)#area 200 range 10.1.1. damn... /28 16 increment 0 16 32 48 64 80 96 112. 10.1.1.96/28 misses the last loopback I guess so we could either accept that or increase to a /27.
    area 200 10.1.1.96 mask? 255.255.255.224
    7. Redistribute the loopback network on router West into OSPF.
    R4(config-rtr)#redistribute connected subnets.
    8. Create virtual links as necessary for full connectivity.
    R1(config-rtr)#area 100 virtual-link 0.0.0.2
    R2(config-rtr)#area 100 virtual-link 0.0.0.1
    9. Make sure that all loopback interfaces are advertised with the correct subnet mask.
    int lo0
    ip ospf network point-to-point

    Tomorrow I'll probably review my notes on OSPF, and working on memorizing all the LSAs and stuff. I also need to look at the ip ospf cost command.
    Last edited by fredrikjj; 10-07-2013 at 10:00 AM.
    Reply With Quote Quote  

  7. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #31
    Day 34

    Re: the talk about network types yesterday. I've now figured out the purpose of point-to-multipoint. In a full mesh topology, having a DR isn't a good idea because if a router loses it's direct layer 2 connection to the DR, it loses its ability to send LSAs to that DR despite still having an indirect path to it via other routers. You would still be able to ping the DR in that scenario, but OSPF won't function properly.

    In a hub-and-spoke this doesn't matter because if the connection to the DR is lost, there's no other paths anyway, but If you are paying extra for a full mesh you want the network to still be functional even if one specific circuit goes down. Point-to-multipoint creates the magic sauce that makes that happen.

    I also did some debugging on the adjacency process, trying to break it in various ways.

    How the adjacency process works:
    (debug output is from 'debug ip ospf adj')

    1. The router sends hello packets out the interface when OSPF is enabled. Before the router has received a hello packet from another router it's in the DOWN state.

    2. When the router receives a hello packet from another router it goes into 'INIT'
    OSPF: Rcv DBD from 0.0.0.2 on FastEthernet1/0 seq 0x20B opt 0x52 flag 0x7 len 32 mtu 1500 state INIT

    The FLG says a hello packet makes a router go into INIT, but this output clearly says DBD which must stand for database descriptor, packet type 2. The DBD describes the LSAs in a router's database. Now, this could mean that the debug output says DBD but it was actually a hello packet that was received. Or, it was an actual DBD packet. Either way, it's mildly confusing.

    3. When the router receives a hello from another router it adds that router's router-id to its own hello packets. Once a router receives a packet with its own router-id it knows that it has established communication with another router and goes into the two-way state.

    OSPF: 2 Way Communication to 0.0.0.2 on FastEthernet1/0, state 2WAY

    4. At this point, if the network type is broadcast, there's a DR/BDR election according to priority settings, or highest router-id if the same priorities.

    OSPF: Elect BDR 0.0.0.1
    OSPF: Elect DR 0.0.0.2

    5. The routers now want to synchronize their databases.

    FastEthernet1/0 Nbr 0.0.0.2: Prepare dbase exchange
    OSPF: Send DBD to 0.0.0.2 on FastEthernet1/0 seq 0x10B7 opt 0x52 flag 0x7 len 32
    OSPF: Rcv DBD from 0.0.0.2 on FastEthernet1/0 seq 0x1103 opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART
    NBR Negotiation Done. We are the SLAVE

    The router on the other side has become MASTER. The FLG doesn't go into specifics as to what the significance of this master/slave relationship is.

    6. The actual exchange takes place

    OSPF: Rcv DBD from 0.0.0.2 on FastEthernet1/0 seq 0x25E3 opt 0x52 flag 0x1 len 72 mtu 1500 state EXCHANGE
    OSPF: Exchange Done with 0.0.0.2 on FastEthernet1/0
    OSPF: Send LS REQ to 0.0.0.2 length 12 LSA count 1
    OSPF: Send DBD to 0.0.0.2 on FastEthernet1/0 seq 0x25E3 opt 0x52 flag 0x0 len 32
    OSPF: Rcv LS UPD from 0.0.0.2 on FastEthernet1/0 length 64 LSA count 1
    OSPF: Synchronized with 0.0.0.2 on FastEthernet1/0, state FULL

    7. The database is now in synch with the neighbor and they are both in the 'FULL' state.

    //Mismatched timers
    So why even care about this type of debugging? After all, as long as you double check that the variables that must match do in fact match (area, hello/dead intervall, authentication, stub flag), shouldn't things just work? Yes, but for example, what if you can't log in to the other device because it's managed by someone else. If all you got is show ip ospf neighbor, and that shows you nothing, what do you do? You could call that other administrator up and say "IT IS NOT WORKING!", or you could go deeper.

    I configured a hello intervall of 9 seconds instead of 10 on the other router. debug ip ospf adj won't give you anything, and show ip ospf neighbor gives you this, incredibly useful output:

    R1#show ip ospf neigh
    <blank>
    R1#
    I
    nstead, let's turn on debug ip ospf hello.

    OSPF: Rcv hello from 0.0.0.2 area 0 from FastEthernet1/0 1.1.1.2
    OSPF: Mismatched hello parameters from 1.1.1.2
    OSPF: Dead R 36 C 40, Hello R 9 C 10 Mask R 255.255.255.0 C 255.255.255.0

    We're able to determine that the remote hello timer of 9 doesn't match ours (and dead the timer of 36 - it defaults to 4 times the hello). Now, instead of calling and saying "It's not working" you'd be able to say "it seems like the hello timers you guys told us to use don't match what you are actually running on your end". You'll sound like you know what you are talking about and the issue will probably be resolved faster. And even if you had access to the other device, this would probably be quicker than actually double checking all the parameters manually.

    Another interesting thing I found when I tried to deliberately break the adjaceny process is that a point-to-point interface will play with a broadcast interface. At least on the point-to-point ethernet segment I'm using for testing. I suppose I shouldn't be surprised since it's not mentioned that those need to match. Don't ask me if this has any implications.

    //Area mismatch

    Next I messed around with area mismatches. OSPF won't be able to form an adjaceny if the area # doesn't match. The problem is that the debug ip ospf hello command we used previously is insufficient.

    R3(config-if)#
    *Oct 24 04:41:55.639: OSPF: Send hello to 224.0.0.5 area 2 on Serial1/0 from 10.0.0.2
    R2(config-if)#
    *Oct 24 04:43:34.359: OSPF: Send hello to 224.0.0.5 area 1 on Serial2/0 from 10.0.0.1
    No hellos are received according to this output, which I find suspect to be honest.
    If we go back to debug ip ospf adj, we're informed of the problem immediately:

    R3#debug ip ospf adj
    OSPF adjacency events debugging is on
    R3# OSPF: Rcv pkt from 10.0.0.1, Serial1/0, area 0.0.0.2 mismatch area 0.0.0.1 in the header

    Another failure scenario in the adjacancy process that I came up with is if one side of the link is non-broadcast and they forgot to tell you. How would you troubleshoot this? You probably won't beacause it'll still work. Presumably because the broadcast side of the link will multicast its IP address, and then the other side will unicast the response. But, if you configure both sides of the link to non-broadcast, they won't become adjacent even if you can ping 224.0.0.5 just fine.

    //Mismatched stub flag

    Seen with debug ip ospf hello
    OSPF: Rcv hello from 0.0.0.2 area 2 from Serial1/0 10.0.0.1
    OSPF: Hello from 10.0.0.1 with mismatched Stub/Transit area option bit
    debug adjaceny won't show anything.

    Why is there such inconsistency in what debug commands show what when it comes to the adjaceny process?

    //authentication.

    debug ip ospf adj will show you mismatched authentication
    OSPF: Rcv pkt from 10.0.0.1, Serial1/0 : Mismatch Authentication type. Input packet specified type 2, we use type 0
    type 0: null
    type 1: simple
    type 2: md5
    If we have the right type, but the wrong key we get:
    OSPF: Rcv pkt from 10.0.0.1, Serial1/0 : Mismatch Authentication Key - No message digest key 1 on interface

    //LSA
    I've pretty much memorized the LSAs by repeatedly drawing diagrams of their propagation. I'm a little bit confused about type 2 LSAs though. Why do we need them when we have type 1s? The FLG is fairly sparse on details, but from what little information is there, I've imagined that type 1 LSAs don't actually contain the full information about transit networks, and only point to the DR. The type 2 LSA then informs the router about the actual full details about that network, should it be required. Is this how it works?
    Reply With Quote Quote  

  8. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #32
    Day 35

    More OSPF. After a few hours though I started to feel like there were some very steep diminishing returns so I decided to answer the 40 review questions in the FLG instead. I messed up on two questions, and only because they tricked me. At this point, any additional information I manage to memorize about OSPF is probably going to be forgotten by December anyway so I'm I'm moving on to EIGRP.
    Last edited by fredrikjj; 10-09-2013 at 10:03 AM.
    Reply With Quote Quote  

  9. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #33
    Day 36

    I had a job interview that fell flat. Demoralized, I spent the rest of the day catching up on on my favorite podcasts instead of studying EIGRP.
    Last edited by fredrikjj; 10-10-2013 at 12:07 PM.
    Reply With Quote Quote  

  10. Senior Member
    Join Date
    Feb 2013
    Location
    Texas
    Posts
    108

    Certifications
    A+, Net+, CCNA, BCNE, CCNP,BCNP, CCDA, BA in Poli Sci and History, MPA (Masters in Public Administration)
    #34
    Sorry to hear that man. I'm sure something will come up. Don't kick yourself around for catching up on podcasts. I do that all the time.
    Reply With Quote Quote  

  11. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #35
    Quote Originally Posted by TBickle View Post
    Sorry to hear that man. I'm sure something will come up. Don't kick yourself around for catching up on podcasts. I do that all the time.
    Reply With Quote Quote  

  12. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #36
    Day 37

    I reviewed the FLG chapter on EIGRP and took notes whenever I felt that it was a productive thing to do. The goal was to identify strengths and weaknesses.

    My focus was on how DUAL works, the EIGRP packets, some configuration, and the section about query scoping at the end of the chapter, which I'm not quite done with. This process took seven hours or so and resulted in a substantial number of pages of handwritten notes. I consistently can't sleep for several hours after studying for that amount of time though which is quite annoying. Maybe I'm STUCK IN ACTIVE... haha.

    Today I'm going to finish up the query scoping section and do some experiments with those features. The SLM doesn't have anything related to it so I guess I'll just have to build something myself.


    Bonus tech question:
    I'm been thinking a bit about the supposed advantage of the "hybrid metric", and if someone wants to defend delay as a valid metric feel free to educate me. My logic is basically that if your network is local, you'll have super low latency everywhere unless you are totally screwed by congestion, in which case you have bigger problems.

    If you route on a worldwide scale where delay starts to matter due to physics, wouldn't you care a lot more about using the _right_ link. I.e. manual policy becomes more important than trusting some routing protocol to make the right decision. And, wouldn't two links to the same destination have roughly the same latency anyway unless you literally go opposite directions around the world?

    That leaves us with bandwidth basically, and it starts looking like a worse version of OSPF's link costs because EIGRP uses the lowest bandwidth along the path, and while you probably can create topologies where that would makes sense, I can see it making suboptimal decisions as well.

    If a device is connected to 1 gig, and you move to 10 or 40 gig down the path, the metric will not take the difference between those 10 and 40 gig pipes into account unless you manually configure the 1 gig to the same BW as the 40 gig in which case the 10 gig will seem worse. OSPF solves that problem by default without trickery. And generally, don't end users and servers generally have their lowest bandwidth at their closest layer 3 device, always creating this problem? You wouldn't connect a server to 10 gig if the next hop is 1 gig, would you. My ideas here aren't based on any kind of pratical experience so feel free to school me.
    Last edited by fredrikjj; 10-11-2013 at 10:54 AM.
    Reply With Quote Quote  

  13. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #37
    Day 38-40

    I finished up the Query stuff on Friday, reviewed my notes, and then more or less took the weekend off. I've also decided to get the 101 CCNP Labs book because I've heard that that it has some difficult material, and difficulty motivates me.
    Last edited by fredrikjj; 10-14-2013 at 12:57 PM.
    Reply With Quote Quote  

  14. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #38
    Day 41

    Read the short path control chapter, took notes and labbed up some of the stuff on Offset lists, IP SLA and PBR. I struggled a bit with PBR because I tried to do it with prefix lists and for the life of me I couldn't get it to work. Standard access lists worked fine, but I had no luck with specific source-desitination extended lists like "permit ip host <source ip> host <destination ip>". It's supposed to work, right, so I must have made some kind of mistake somewhere. I put set interface null0 at the end of the route-map for all these tests as an easy way to gauge if traffic was matched or not (and debug ip policy).

    With prefix lists the problem was that despite having a specific network in the list, it matched all IPs and policy routed them according to that match/set combination. With extended access lists debug ip policy told me that the packets came in with the specific src and dst I had put in my extended ACL, but they still weren't matched, got bumped down to the null0 statement and got dropped. I found it very frustrating.

    I've also taken a first look at the BGP labs in "101 CCNP Labs" at http://www.##########.net/public/department601.cfm and they seem pretty brutal. My goal this week will be to refresh and learn BGP to the point where I can solve most of those. It's by far my weakest area right now after the recent work I've done on EIGRP, OSPF and redistribution, but 30-40 hours of studying should take care of that.
    Last edited by fredrikjj; 10-18-2013 at 10:27 AM.
    Reply With Quote Quote  

  15. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #39
    Day 42

    A day of BGP. I basically read and took notes on the first 40 pages of the chapter. Nothing really suprised me since I've read this material before and done labs, but I went into more detail. Today I plan to move into the configuration and verification sections. I've also realized that the very first lab in the "101.." requires communities which is covered in the appendix. I guess this means that I'll work my way through all the text before I start labbing.
    Reply With Quote Quote  

  16. Junior Member
    Join Date
    Oct 2013
    Posts
    11

    Certifications
    A+, Network+, MCSA: Windows Server 2012
    #40
    Keep up the good work. Use various materials - then the pieces will fall into place.
    Reply With Quote Quote  

  17. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #41
    Quote Originally Posted by Goodspeed View Post
    Keep up the good work. Use various materials - then the pieces will fall into place.
    I appreciate the support.
    Reply With Quote Quote  

  18. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #42
    Day 43

    Did some more BGP and got into the meat and poatoes of the configuration. That leaves me with configuration of the attributes and the appendix. I also read this sentence about the "network" command:

    If the mask is not specified, this command announces only the classful network number; at
    least one subnet of the specified major network must be present in the IP
    routing table to allow BGP to start announcing the classful network as a BGP
    route. However, if you specify the network-mask, an exact match to the network
    (both address and mask) must exist in the routing table for the network to be
    advertised.


    Verification:


    R1 and R2 are directly connected on 10.1.12.0/24.

    R1#show run | s router bgp
    router bgp 1
    neighbor 10.1.12.2 remote-as 2

    R1#show ip bgp neighbors
    BGP neighbor is10.1.12.2, remote AS 2, external link

    R2show run | s router bgp
    router bgp 2
    neighbor 10.1.12.1 remote-as 1

    R2#show ip bgp neighbors
    BGP neighbor is10.1.12.1, remote AS 1, external link

    I create a subnet of the major network 20.0.0.0/8 as a loopback interface on R1.

    R1(config-router)#int lo0
    R1(config-if)#ip add 20.0.0.1 255.255.255.0

    It shows up in therouting table:

    R1#show ip route
    C 20.0.0.0/24 is directly connected,Loopback0

    Now, according to the text I quoted above I should be able to advertise 20.0.0.0/8 with network 20.0.0.0 since “at least one subnet of the specified major network must bepresent in the IP routing table to allow BGP to start announcing the classfulnetwork as a BGP route”

    R1#show run | s router bgp
    router bgp 1
    network 20.0.0.0

    But,

    R2#show ip bgp
    <blank>
    R2#

    However, if I change the mask of the loopback to /8 the network is advertised.

    R1(config)#int lo0
    R1(config-if)#ip add 20.0.0.1 255.0.0.0

    R2#show ip bgp
    Network Next Hop Metric LocPrf Weight Path
    *> 20.0.0.0 10.1.12.1 0 0 1 i

    Conclusion: the FLG is wrong and/or they've changed this behavior in more recent releases of IOS.Clearly, even a major network requires an exact match in the routing table. Am I missing something?
    Reply With Quote Quote  

  19. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #43
    Day 44

    I finished my notes on the BGP chapter. I ended up with significantly more pages compared to the IGP chapters which reflects the fact that I'm much less confident with this protocol. I also solved the first BGP lab out of the 11 in the '101 CCNP Labs' book. When that final ping came back, I got the biggest grin on my face. Easily the best “I can't believe that actually worked” moments so far. These labs are supposed to be harder than the exam so my rules are basically that I can't look at the answers, but I can use my notes, the FLG, etc.

    bgplab1.jpg

    All this stuff is freely available on their website that I can't link to due to some kind of filter.

    Task 1
    Configure hostnames and IP addressing on all routers as illustrated in the network topology.

    Thankfully, this wasn't a problem.

    Task 2
    Without using peer groups, configure internal BGP on R1, R2, R3, and R4 as follows:
    1. Statically configure a BGP router ID using the router number, e.g. 1.1.1.1 for R1, etc.

    router(config-router)#bgp router-id 1.1.1.1

    2. All routers should peer using their physical interface addresses
    3. R1 should peer to R2 and R3
    4. R2 should peer to R1
    5. R3 should peer to R1 and R4
    6. R4 should peer to R3

    router(config-router)#neighbor 10.0.0.2 remote-as 254
    repeat

    7. All routers should use the TCP MD5 authentication password 'CCNP'

    router(config-router)#neighbor 10.0.0.2 password CCNP

    8. BGP Hellos should be sent out every 5 seconds
    9. All of the BGP speakers should advertise a Hold Time of 15 seconds

    router(config-router)#neighbor 10.0.0.2 timers 5 15

    10. The COMMUNITIES attribute (standard) should be supported

    This feature needs to be manually activated or the router won't pass the community information along to peers
    router(config-router)#neighbor x.x.x.x send-community standard
    This needs to be added to all neighbor statements.

    Task 3
    Advertise the 150.1.1.0/24, 150.2.2.0, and 150.3.3.0/24 subnets on R1, R2, and R3 via BGP. These
    prefixes must be advertised with the standard community values listed below. You are NOT allowed to
    redistribute these prefixes into BGP. Additionally, you are NOT allowed to use outbound or inbound route-
    maps when completing this task. Ensure that the community values are displayed in ASN:nn (RFC 1997 -
    BGP Communities Attribute) format. Verify your configuration using the appropriate commands.
    1. The 150.1.1.0/24: community value of 254:111
    2. The 150.2.2.0/24: community value of 254:222
    3. The 150.3.3.0/24: community value of 254:333

    You activate the RFC1997 standard with the command router(config)#ip bgp-community new-format because the Cisco default is NN:AS instead of AS:NN. Assigning the community values is done with a route-map on the network statement.
    #route-map COMMUNITY permit 10
    set community 254:111
    #network 150.1.1.0 mask 255.255.255.0 route-map COMMUNITY

    Task 4
    Configure your network so that all 150.x.x.x/24 subnets can reach each other. You are NOT allowed to
    use any static routes in your solution. Additionally, you are NOT allowed to advertise or redistribute the
    150.4.4.0/24 subnet into BGP on R4. Instead, consider other BGP features to complete this task. You are
    NOT allowed to configure R2 or R4. Additionally, you are NOT allowed to configure a dynamic routing
    protocol to complete this task.

    Next, verify your configuration using the appropriate commands as well as the extended ping function.
    For example, on R1 use the extended ping function to send a ping to 150.2.2.2 sourced from 150.1.1.1,
    etc, etc. All pings should work when the task is completed correctly .

    This is where things got interesting and where I spent most of my time. If you think that my solution is crude and demonstrating a lack of knowledge of BGP, you are probably right. Anyway. The first problem is that since R3 and R2 aren't peering, they'll never learn each other's 150 segments due to the rule that routers don't send updates learned from IBGP to other IBGP peers.

    Configuring R3 as a route reflector client on R1 solves this problem.
    R1(config-router)#neighbor 10.0.0.6 route-reflector-client

    At this point R1,R2 and R3 all know about the 150.1, 150.2 and 150.3 networks, but since the next-hop is maintained, R2 and R3 have a next-hop to their respective LAN segments that they can't reach. Next-hop-self on R1? No, that is for EBGP. I wasted time at this point searching for some BGP command to fix the problem. I fixed R2 by sending a default BGP route from R1 with:

    R1(config-router)#neighbor 10.0.0.2 default-originate

    Now when R2 tries to find the next hop 10.0.0.6 to reach 150.3.3.0/24, it uses the default route. On R3 I resolved this issue by advertising the network 10.0.0.0/30 from R1.

    R1(config-router)#network 10.0.0.0 mask 255.255.255.252

    R3 is able to find the next hop 10.0.0.2 to 150.2.2.0/24 by looking at this route. We now have full connectivity between R1,R2,R3. The remaining problem is R4 and the 150.4.4.0/24 network. I sent a default route to R4 from R3:

    R3(config-router)#neighbor 10.0.0.14 default-originate

    R1,2,3 have no knowledge of 150.4.4.0/24. R2 will send traffic to R1 through the default, but it won't go beyond that. The only way I manage to solve this was to create an extended ACL on R1 and R3

    R1(config)#access-list 100 permit ip any 150.4.4.0 0.0.0.255

    It permits any traffic with a destination of 150.4.4.0/24.

    I then created a route map on R1 and R3

    R1
    route-map MAGIC permit 10
    match ip address 100
    set ip next-hop 10.0.0.6
    !
    route-map MAGIC permit 20

    R3
    route-map MAGIC permit 10
    match ip address 100
    set ip next-hop 10.0.0.14
    !
    route-map MAGIC permit 20

    This route-map is applied to the incoming interfaces and locally. If it isn't activated locally, traffic sourced from the router itself won't have its next-hop modified.

    R1(config-if)#ip policy route-map MAGIC
    R1(config)#ip local policy route-map MAGIC

    R3(config-if)#ip policy route-map MAGIC
    R3(config)#ip local policy route-map MAGIC

    Once traffic actually gets to R4, it's returned to R3 through the default route, and R3 can handle the return traffic just fine since that router has normal reachability to the other LAN segments.

    The requirements are now met without touching R2 or R4 or using an IGP or static routes, but I get the feeling that the actual solution looks different. BGP gurus, feel free to chime in.
    Reply With Quote Quote  

  20. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #44
    Day 45

    Finished two more BGP labs. Hard as ****, but I did it. I made similar write ups like the one above, but I doubt anyone wants to read a 3,000 page post.
    Reply With Quote Quote  

  21. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #45
    Day 46

    Did 3 more bgp labs. These were less painful than the three I did before so I think it's starting to click. I have identified 2 very specific weak points; using as-path and regular expression, and those ge/le keywords in prefix-lists. I know what they do, but when it comes down to crafting a very specific as-path list or prefix list, I often fail. I found this post on INE's blog http://blog.ine.com/2008/01/06/under...r-expressions/ that I haven't read yet, but I have a feeling that it's exactly what I need. I do find it strange that it isn't covered in the FLG when it's something that you obviously need to know when configuring BGP.

    PS.
    I wish I could go live in Brian McGahan's basement.
    Last edited by fredrikjj; 10-20-2013 at 11:35 AM.
    Reply With Quote Quote  

  22. Resident Underachiever EdTheLad's Avatar
    Join Date
    May 2005
    Location
    Globe trotter, nfa
    Posts
    2,118

    Certifications
    CCNP/CCIP/IE Written
    #46
    Quote Originally Posted by fredrikjj View Post

    Bonus tech question:
    I'm been thinking a bit about the supposed advantage of the "hybrid metric", and if someone wants to defend delay as a valid metric feel free to educate me. My logic is basically that if your network is local, you'll have super low latency everywhere unless you are totally screwed by congestion, in which case you have bigger problems.

    If you route on a worldwide scale where delay starts to matter due to physics, wouldn't you care a lot more about using the _right_ link. I.e. manual policy becomes more important than trusting some routing protocol to make the right decision. And, wouldn't two links to the same destination have roughly the same latency anyway unless you literally go opposite directions around the world?

    That leaves us with bandwidth basically, and it starts looking like a worse version of OSPF's link costs because EIGRP uses the lowest bandwidth along the path, and while you probably can create topologies where that would makes sense, I can see it making suboptimal decisions as well.

    If a device is connected to 1 gig, and you move to 10 or 40 gig down the path, the metric will not take the difference between those 10 and 40 gig pipes into account unless you manually configure the 1 gig to the same BW as the 40 gig in which case the 10 gig will seem worse. OSPF solves that problem by default without trickery. And generally, don't end users and servers generally have their lowest bandwidth at their closest layer 3 device, always creating this problem? You wouldn't connect a server to 10 gig if the next hop is 1 gig, would you. My ideas here aren't based on any kind of pratical experience so feel free to school me.
    Just, saw this and thought i'd comment.
    On Eigrp both delay and bandwidth are configurable per interface, the delay can be used in the same way as ospf uses cost.Bandwidth can be used as an extra knob to fine tune. So the hybrid metric gives you more flexibility.
    Reply With Quote Quote  

  23. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #47
    Ed: Thanks


    Day 47 - BGP week post mortem

    Sunday night I finally finished the last of the 10 BGP labs I had planned to do this week, save one or two tasks that I simply can't solve with those restrictions in place. I learned I a lot, I think, and at some points I even felt like I knew what I was doing. No points for speed though, and occasionally I got stuck for hours going over notes and the BGP command reference. While the conceptual knowledge you need is in the FLG for the most part, some of the actual commands definitely are not.

    I'm about half way through the 3 months I've allowed myself to study for this thing and I'm satisified with my rate of progress. My main concern is that I won't be able to memorize enough stuff to pass the exam.
    Last edited by fredrikjj; 10-21-2013 at 10:21 AM.
    Reply With Quote Quote  

  24. Member lincis_aus's Avatar
    Join Date
    Aug 2010
    Location
    Australia
    Posts
    50

    Certifications
    BSc Network Engineering, CCENT, CCNA, ITIL Foundation v3, CCNA:Voice, CCNA:Security, CCNP R&S
    #48
    First of all, I want to commend you for your effort and determination to get this CCNP under your belt. If you continue like this I have no doubt you will pass with flying colours, and also have a long and prosperous career in IT.

    In regards to remembering stuff, make sure you understand what you are reading, therefore you will not need to remember any of it. It will be stuck in your head and there is nothing you can do about it (sort of like getting a song stuck in your head for the whole day)

    I know that Cisco makes you learn some annoying and trivial stuff like STP/RSTP timers, phases, metrics, troubleshooting steps, some Cisco marketing BS etc.., I always found flash cards to be very helpful for that.

    I am about to start my CCNP study with the Switch OCG. I have gone through the whole CCNP course twice at college and university, so i think its time for me to demolish it.

    Good luck
    Reply With Quote Quote  

  25. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #49
    Quote Originally Posted by lincis_aus View Post
    First of all, I want to commend you for your effort and determination to get this CCNP under your belt. If you continue like this I have no doubt you will pass with flying colours, and also have a long and prosperous career in IT.
    What's funny is that doesn't really require much effort. Getting started can be a bit rough some days, but lab work especially I find very enjoyable. I've actually put some cycles into trying to figure out why; for me, the constant feedback you get from tinkering with the CLI induces a state of flow that rivals the best of video games. The very obvious connection between theory and practice is something that I love as well, and this field is pretty much an ideal match for me as far as I'm concerned.

    In regards to remembering stuff, make sure you understand what you are reading, therefore you will not need to remember any of it. It will be stuck in your head and there is nothing you can do about it (sort of like getting a song stuck in your head for the whole day)
    I know that Cisco makes you learn some annoying and trivial stuff like STP/RSTP timers, phases, metrics, troubleshooting steps, some Cisco marketing BS etc.., I always found flash cards to be very helpful for that.
    Certainly. When I studied for the CCNA I remember having trouble remembering ADs for different routing protocols and things of that nature. I think it was a case of that material being so shallow that it actually made it harder to remember. Except for Frame Relay. I can configure FR like it's nobody's business.

    The CCNP seems to be in this weird middle ground where you don't need to know everything, but enough to make you think that you do. I have a feeling that more than one CCNP has messed stuff up because he thought he was the ****, and applied his "expertise" to a real network, lol.

    I am about to start my CCNP study with the Switch OCG. I have gone through the whole CCNP course twice at college and university, so i think its time for me to demolish it.

    Good luck
    It makes me kind of jealous that people get to take actual college classes on this stuff. I even heard about some Master's program in the US that was basically a CCIE prep thing. How cool is that.
    Last edited by fredrikjj; 10-21-2013 at 10:28 PM.
    Reply With Quote Quote  

  26. Senior Member
    Join Date
    Sep 2013
    Location
    Sweden
    Posts
    866

    Certifications
    CCNP
    #50
    IPv6 and GRE tunnels are my main weak areas remaining, and I'll probably spend the rest of this month on it. The FLG seems to be very heavily focused on the implementation side of things with a significant number of pages on how to configure the IPv6 routing protocols which, to be perfectly honest, is very straight forward if you know how their IP counterparts work. With that in mind I might check out some additional online sources.
    Last edited by fredrikjj; 10-22-2013 at 01:03 PM.
    Reply With Quote Quote  

+ Reply to Thread
Page 2 of 8 First 12 3456 ... Last

Social Networking & Bookmarks