Sometimes when configuring BGP you’ll come accross routes that show rib-failure. What exactly does this mean?
Have a look at this output:
R3#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
r> 172.16.220.0/24 172.16.220.1 0 0 3 i
*> 192.68.0.0/16 172.16.220.1 0 0 3 {2,1} i
*> 192.68.10.0 172.16.220.1 0 3 2 i
172.16.220.0/24 is showing up as r> – but what exactly is going on? There is a command you can use to see what’s happened: show ip bgp rib-failure
R3#sh ip bgp rib-failure Network Next Hop RIB-failure RIB-NH Matches 172.16.220.0/24 172.16.220.1 Higher admin distance n/a
Here it’s telling me that the BGP could not be injected into the routing table as there is already a route with a higher administrative distance there. This is proved with the ip routing table:
R3#sh ip route 172.16.220.0
Routing entry for 172.16.220.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via FastEthernet0/1
Route metric is 0, traffic share count is 1
Essentially a RIB-failure is a note letting you know that the route is in BGP, but it has not been injected into the IP routing table even though it is a valid and best route
Topology used is over here: http://mellowd.co.uk/ccie/?p=243
BGP Lab 11:
- All routers are peered via BGP
- Router9 has the network 24.83.176.1/24 attached via a loopback
- Router2 has the network 24.83.177.1/24 attached via a loopback
- All networks MUST be inserted into the BGP process
- Now ensure that Router8 and Router1 see the full aggregate of 24.83.176/23 advertised. More specific routes MUST be supressed. i.e. Router1 and Router8 should have the aggregate ONLY – Do this WITHOUT removing any of the networks from the BGP process
- Now change the configuration so that Router1 and Router8 get the aggregate as well as the more specific routes, however using a community tag (on Router2), ensure that Router1 does NOT advertise the more specific routes to Router6.
- Router6 should still get the aggregate route
- Check to make sure Router1 has all the routes and Router6 ONLY has the aggregate route
Click on the thumbnail for the full topology:
Topology used is over here: http://mellowd.co.uk/ccie/?p=243
BGP Lab 10:
- CompanyA is a customer of ISP1
- CompanyA is peered with CompanyB which is NOT a customer of ISP1
- ISP1 advertises the loopbacks of both Router8 and Router9, however wants to ensure that only it’s own customers know about 8.8.8.8
- ISP1 does not care that all routers know about 9.9.9.9
- ISP1 does not trust CustomerA to put the right measure in place, so you need to do it from the ISP1 side.
- In other words, make sure that CompanyA knows about 8.8.8.8 but force it not to advertise that route any further
Click on the thumbnail for the full topology:
Topology used is over here: http://mellowd.co.uk/ccie/?p=243
BGP Lab 9:
- ISP1 is running OSPF internally so that all loopbacks are accessible
- Router1 has the network 172.20.1.0/24 attached to it (via a loopback)
- Router8 has the network 172.20.8.0/24 attached to it (via a loopback)
- Ensure both these networks are advertised by both Router1 and Router8
- ISP1 contains the entire 172.20.0.0/16 network. Ensure this aggregate is always advertised out, no matter the condition of the more granular networks
- Using MED, ensure traffic from Router10 to 172.20.1.0/24 goes via Router2 and traffic to 172.20.8.0/24 goes via Router9
- Ensure the MED comes from the OSPF metric itself
Click on the thumbnail for the full topology:
Topology used is over here: http://mellowd.co.uk/ccie/?p=243
BGP Lab 8:
- Address as normal in the topology – Add the loopback of 99.99.99.99 and 22.22.22.22 to Router’s 9 and 2 respectively
- All routers are peered via BGP with OSPF running as well
- Use a filter on AS500 to ensure it is non-transit
- Company1 now wants to prepend it’s AS number 3 times for any route sent off to Customer2
- Allow Customer3 to transit through ISP1
- Ensure Customer3′s Private-AS number is stripped off before advertising it out
- Allow Company1 and Company2 to get to Customer3
Click on the thumbnail for the full topology:
New lab for today. This one is a little more complex than the rest I’ve posted thus far. It should give you good practice. Topology used is over here: http://mellowd.co.uk/ccie/?p=243
BGP Lab 7:
- Customer1 and Customer2 are both customers of ISP1
- ISP1 is running OSPF internally
- ISP1 has decided to give each of them a private AS number as these companies are rapidly expanding
- Customer1 and Customer2 then buy a high speed link between the 2 of them and run OSPF. You need to ensure that they use the high speed link when going to each others subnets and NOT transit through ISP1 – Though they need to transit when the frame-relay link is down
- Ensure that Customer1 and Customer2 will never use each other for transit when going out to ISP2
- Static routes are NOT allowed
- Ensure that ISP1 sends all routes to ISP2, but the private AS numbers need to be stripped
- Ensure that ISP2 uses the link to Router2 when getting to Customer2 and uses the link to Router3 when going to Customer1
Click on the thumbnail for the full topology:
As you may know, each interface on a router should be in a separate network or subnet. This is so that when a packet comes in it knows exactly which interface to send it out of. If you try and create 2 interfaces on a router it won’t allow you to open them both. Here is an example:
R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#int fa0/0 R1(config-if)#ip add R1(config-if)#ip address 10.1.1.1 255.255.255.0 R1(config-if)#int fa0/1 R1(config-if)#ip address 10.1.1.2 255.255.255.0 R1# R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#int fa0/0 R1(config-if)#no shut R1(config-if)#int fa0/1 R1(config-if)#no shut % 10.1.1.0 overlaps with FastEthernet0/0 FastEthernet0/1: incorrect IP address assignment
You can see here that IOS is telling me that Fa0/0 already falls in the 10.1.1.0/24 range, therefore I cannot have another interface in the same.
However, you CAN do this on serial ports:
R1#sh run int s1/1 Current configuration : 89 bytes ! interface Serial1/1 ip address 192.168.1.1 255.255.255.0 serial restart-delay 0 end R1#sh run int s1/2 Current configuration : 89 bytes ! interface Serial1/2 ip address 192.168.1.2 255.255.255.0 serial restart-delay 0 end R1#sh ip int brief Interface IP-Address OK? Method Status Protocol Serial1/1 192.168.1.1 YES manual up up Serial1/2 192.168.1.2 YES manual up up Loopback0 1.1.1.1 YES NVRAM up up
Even the route shows up correctly:
R1#sh ip route
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
C 192.168.1.0/24 is directly connected, Serial1/1
is directly connected, Serial1/2
Why is this? Not sure yet. I wonder also if it’ll cause any kind of loops?
I went ahead and booked the exam for a months time. With a lot going on at work I’m finding it difficult to put in a lot of study time, so I’ll have to see how this goes. It should be enough time and at least it gives me a target to work towards.
I personally like to book my exam as far in advance as possible to give myself a goal. I don’t ever change the data I’ll write otherwise I might just procrastinate.
There’ll be more BGP labs up over the next week as well. I’ve got all kinds of ideas for new ones!
New lab for today. I’ve just completed it myself and it’s a good one for practice. This will cover BGP, EIGRP, OSPF and RIPv2. It will cover redistribution of routes as well. Topology used is over here:http://mellowd.co.uk/ccie/?p=243
BGP Lab 6:
- Customer 1 is running RIPv2 internally and Customer 2 is running EIGRP internally
- Both customers have default routes pointing to ISP1
- Ensure this default route is redistributed into each customer via IGP redistribution
- ISP1 is running OSPF and BGP internally, however Router10 is NOT running BGP
- ISP1 and ISP2 are eBGP peers
- Using redistribution, ensure Customer 2 is able to get to all subnets in Customer1 and vice versa
- ISP2 should be able to get to all loopbacks
- Add another loopback on Router14 with the IP 140.140.140.140. Redistribute it into RIP and then ensure all other routers can ping it without modifying any config on any other router
Click the image for a larger picture of the lab
Third and last BGP lab for today. This one mainly concerns peer-groups, though there is a bit of as_path access lists thrown in as well. Topology used is over here: http://mellowd.co.uk/ccie/?p=243
BGP Lab 5:
- Create a peer group in AS950 so you don’t have to do the same configuration for R2, R9 and R8 all the time
- Ensure R8, R9 and R2 all use R1 as the next hop when leaving the AS
- Use loopbacks in AS950 for iBGP peerings
- Create an AS_PATH access list so that AS60 and AS70 don’t use AS950 as transit, however all routers in AS950 should be able to ping all routers
Click on the thumbnail for the full size image
Comments