Just another Cisco blog
Posts tagged CCIE
CCIP Practice Lab #2
Feb 2nd
This is the second practice lab for my CCIP BGP and MPLS preparation. I’ve added my configs to the first post, let me know if I’ve missed anything. This lab has a lot of overlap with the last one, but I’ve added some more BGP-specific stuff in preparation for my upcoming exam. I have italicized all the changes. Here’s the topology:
Requirements
Core
- P1, P2, P3 and P4 run only MPLS and OSPF, no BGP.
- PE1, PE2, PE3 and PE4 will support EIGRP, OSPF and L2 VPNs to customers C1, C2 and C3.
BGP
- PE1 and PE4 will have an iBGP relationship and will be route reflectors for PE2 and PE3. Use the fewest commands possible.
- Configure MD5 authentication between CE4 and PE1 using the password “cisco1”.
- Configure MD5 authentication between CE4 and Peer1 using the password “cisco1”.
BGP Best Path Selection
Feb 1st
As I gear up for the CCIP BGP exam (hoping to take it in the next few weeks), I’m relearning all the little things I’ve forgotten since BSCI. I had the Best Path criteria memorized for the exam and I’ve since forgotten some of the criteria and the exact order. Google pointed me to these docs:
This one courtesy of Ciscozine:

This one courtesy of Richard Bannister’s CCIE Blog:

These two charts are great, they’ve helped immensely. I love the internet. I’m posting them here for my future use and in case and of you haven’t already seen them.
BGP Peer Groups
Jan 29th
Just a short article today on BGP Peer Groups. I’ve been using them while practice labbing for the CCIP exams, thought I’d toss up a short post.
BGP Peer Groups “reduce the load on system resources by allowing the routing table to be checked only once, and updates to be replicated to all peer group members instead of being done individually for each peer in the peer group.” (-Cisco.com) They can also greatly reduce administrative overhead. They’re somewhat self-explanatory, you specify a Peer Group for two or more neighbors, then apply config to the group instead of each individual neighbor. We’re going to use my CCIP topology, but we’ll just focus on the iBGP peers:
We see that all of our PE routers are running iBGP and they’re fully meshed. Let’s look at PE1′s config without Peer Groups:
router bgp 6500 neighbor 6.6.6.6 remote-as 6500 neighbor 6.6.6.6 update-source Loopback0 neighbor 6.6.6.6 next-hop-self neighbor 7.7.7.7 remote-as 6500 neighbor 7.7.7.7 update-source Loopback0 neighbor 7.7.7.7 next-hop-self neighbor 8.8.8.8 remote-as 6500 neighbor 8.8.8.8 update-source Loopback0 neighbor 8.8.8.8 next-hop-self |
CCIP Practice Lab #1
Jan 28th
This is the first practice lab for my CCIP BGP and MPLS preparation. I have modified the existing topology to add another customer. This lab is somewhat basic, but it incorporates many different technologies.
Requirements
Core
- P1, P2, P3 and P4 run only MPLS and OSPF, no BGP.
- PE1, PE2, PE3 and PE4 will support EIGRP, OSPF and L2 VPNs to customers C1, C2 and C3.
BGP
- All PE routers will have iBGP relationships with each other. Use the fewest commands possible to accomplish this. Ensure multiple paths can be taken to peer with each router.
- PE1 and PE2 will have eBGP relationships with Peer1 and Peer2.
- Peer1 and Peer2 will inject networks from several loopbacks into BGP to simulate the internet.
- Peer1 and Peer2 will have an eBGP relationship.
Lock and Key ACLs
Jan 14th
A coworker recently came to me for help with an issue. We have a server sitting behind a router at one of our remote sites. Certain people need RDP access to this server, but we do not want it open to the world, this seems like an ideal scenario for Lock and Key access lists. Lock and Key ACLs are a way to permit temporary access to a resource. Static ACLs either allow or deny, they can create temporary openings to suit a specific need. In our example it will be a telnet server behind a router. Here’s the topology:
Here we see a host on one side of R1 (Fa0/0) and a server on the other side (Fa1/0). In this example we want very limited access to Telnet on that server. Here’s our config:
interface FastEthernet0/0 description To Host ip address 192.168.1.1 255.255.255.0 ip access-group Telnet in ! interface FastEthernet1/0 description To Server ip address 192.168.2.1 255.255.255.0 ! ip access-list extended Telnet dynamic allow_telnet permit tcp any host 192.168.2.2 eq telnet deny tcp any host 192.168.2.2 eq telnet permit ip any any ! username allow password 0 allow username allow autocommand access-enable host timeout 10 |



Recent Comments