Posts Tagged ‘sample’

Jul
19

The author and poet Maya Angelou said “Words mean more than what is set down on paper. It takes the human voice to infuse them with deeper meaning.”. Well that is certainly what we have attempted to do with the CCIE Voice Deep Dive self-paced Class on Demand series – that is to bring the human instructional voice element to infuse deeper meaning to what is already fantastic Cisco Documentation. Anyone that has set out and determined to undertake the task of studying for and ultimately passing any CCIE Lab exam, knows that at some point during your studies, the words on paper (Cisco Docs, RFCs, books) – while a absolute phenomenal source of information – can at times seem to loose their impact. Perhaps you have been studying too long, read one too many docs, have the time pressure of your family and friends waiting for you to return to be a part of their life, or perhaps you are just starting out on your adventure and don’t know where to begin. Whatever stage you are at or whatever the case may be, it is certainly helpful to have a tutor and mentor there beside you at times, assisting you in understanding what each complex technology’s documentation is trying to teach you, in possibly a deeper and more insightful way than you can manage on your own.

Wait no longer for such help to arrive! INE is happy to announce that each Live-Online Deep Dive course that we have taught has been recorded, and you have the ability to access these extensive repositories of knowledge at any time.

Here are a couple of great demo’s of just a portion of the latest Deep Dive session we held on Globalization & Localization in order to whet your appetite:

Demo 1: Globalization Prezi – Theory and Reasons

Demo 2: Inbound Calling Party Localization

Continue Reading

Tags: , , , , , , , ,

Jun
29

Hello all! Writing to you from the 2009 Networkers Conference in San Fran. I hope all readers around the world are well today and feeling the buzz about Cisco technologies.

We have many of the CCIE R/S Written Bootcamp students testing this week at the Networkers Conference. As such, we made Practice Exam 1 a priority and completed it last night. It is now posted and available in all Member’s Sites.

This 100 question practice exam covers all topics within scope and should defintely pinpoint any of your weak areas. Enjoy!

NOTE: The actual CCIE R/S Written is currently 105 questions, but only 100 of the questions are graded.

Tags: , , , , , , , ,

May
21

On June 15, 2009, the CCIE Security Lab Exam receives the new Core Knowledge section. To help prepare students for this critical new lab exam component, the CCIE Security Core Knowledge Simulation is now available for purchase.

For more information, or to add the product to your shopping cart, use the link below:

CCIE Security Core Knowledge Simulation

Tags: , , , , ,

Jan
27

One of my student friends from Cisco RTP suggested a great weekly addition to our blog – a sample task from a Mock Lab to challenge the blog faithful. Cool idea! Love it! To not spoil your fun when taking our Mock Labs, these tasks have been written special so that there is no carryover.

My first installment is a topic that could easily appear on either the R/S Lab or the Security Lab. Enjoy! You are more than welcome to post your suggested solution in the comments. I will wait a week and then post a solution in there myself – along with some explanation text. If you enjoy this new blog installment, you should check out our products, because they are even better! :-)

Here we go!

8.0 Security

8.1 DoS Protection

You are concerned about DoS attacks against a key perimeter router in your company. Configure R1 so that it limits the aggregate rate of ARP traffic toward the route processor to 75 packets per second. Routing control traffic marked with an IP Precedence value of 6 should be limited to 100 packets per second.

2 points

NOTE: The solution and walkthrough are posted in the comments below dated February 6, 2009. Once again, this is a fraction of what you receive in our products!

Tags: , , , , ,

Oct
23

The rest of volume 1 version 5 is coming… I promise! :) QoS is next, and trust me, it is well worth the wait. Click here for a preview of the be-all and end-all of QoS documents, and you’ll see why it’s taking me so much time for a final tech edit! ;)

Tags: , ,

Aug
26

Note: The following post is an excerpt from the full QoS section of IEWB-RS VOL1 version 5.

Peak shaping may look confusing at first sight; however, its function becomes clear once you think of oversubscription. As we discussed before, oversubscription means selling customers more bandwidth than a network can supply, hoping that not all connections would use their maximum sending rate at the same time. With oversubscription, traffic contract usually specifies three parameters: PIR, CIR and Tc – peak rate, committed rate and averaging time interval for rate measurements. The SP allows customers to send traffic at rates up to PIR, but only guarantees CIR rate in case of network congestion. Inside the network SP uses any of the max-min scheduling procedures to implement bandwidth sharing in such manner that oversubscribed traffic has lower preference than conforming traffic. Additionally, the SP generally assumes that customers respond to notifications of traffic congestion in the network (either explicit, such as FECN/BECN/TCP ECN or implicit such as packet drops in TCP) by slowing down sending rate.

Continue Reading

Tags: , , , , ,

Jul
19

For the benefit of those who do not have access to the lab below is the task and the diagram:

4.11. IGP Redistribution
• Redistribute between RIP and OSPF on SW1.
• Redistribute between OSPF and EIGRP on R2, R3, and R4.
• Ensure that full reachability is maintained throughout the IGP domain when the Frame Relay circuit between R3 and R5 is down.

3 Points

First off this task is only worth 3 points but will take most people 45 minutes to 1 hour to complete due to the fact the requirements create a routing loop. This means that it’s really not worth 3 points in the real lab due to the fact you’re giving away 1 hour of your 8 hours for just 3 points. In the real lab most people would be better off just getting full IP reachability and moving on. Think about it like this. If you could give up 3 points in every lab and implement you own solution to obtain full IP reachability would you be better off?

When you run across a redistribution task in a lab your first goal is to determine what is the minimum redistribution needed to achieve full reachability. This is your “safety net” in the event you are not able to complete the task as required or do not have the time to fully complete the task as required. You can pass the lab without getting these 3 points but you can’t really expect to pass the lab without having full IP reachability.

Since our first goal is just to determine what is needed to obtain full IP reachability lets look at this network and determine where we need to perform redistribution to achieve this. Obviously we must redistribute between RIP and OSPF on SW1 to provide reachability between the OSPF and RIP domains. Since this will be a single point of redistribution between RIP and OSPF and these protocols are only both run on one router (SW1) we will not have any problems. This means we can just redistribute RIP into OSPF, then OSPF into RIP and finally verify our redistribution by viewing the routing tables and doing some basic pinging. No tagging, filtering, distribute-list, etc is needed on SW1.

Once the RIP and OSPF redistribution is finished and verified we should then move onto the EIGRP and OSPF redistribution. Do not make the mistake of moving onto the EIGRP and OSPF redistribution without first verifying your RIP and OSPF redistribution. You must verify each stage of the network as it’s built. If you wait until the end of the IGP section to test for full IP reachability it will be much harder to determine what the cause of the problems are. Think about it like this. If I gave you a network and told you to find 10 errors in it would it be easier to find the 10 errors after I’ve applied all of the configuration or would it be easier to check for the errors as I apply each part of the configuration? If you didn’t answer the latter I would hope you never have aspirations on becoming an airline engine inspector ;-)

First off we need to determine what are the minimum points of redistribution needed between OSPF and EIGRP to obtain full IP reachability. Normally this is easy to determine but in this network we have a backup link being used. In the real lab we don’t need to worry about redundancy or sub-optimal routing unless specified directly or indirectly. In this case we need to take redundancy into consideration since full IP reachability will need to be obtained when the network is in two different states. The first state is when the backup link is in the standby mode. The second state is when the backup interface is active due to the fact the primary link is down. In this case the backup link is the serial between R4 and R5 and the primary link is the Frame Relay connection between R3 and R5.

Now that we know what items to take into consideration for the EIGRP and OSPF redistribution we can determine that at a minimum EIGRP and OSPF will need to be redistributed on R4 and either R2 or R3. R4 is selected for redistribution because when the backup link is active it will need to provide connectivity between R5 and the rest of the network.

Where we start having problems is with the redistribution on R2 or R3 so lets look at what the problem is. OSPF routes going into EIGRP will not present a problem because once the OSPF routes are in EIGRP they will have a higher AD. Remember that the problems with redistribution occur when we take a higher AD protocol and then redistribute it into a lower AD protocol and finally attempt to redistribute it back into the original higher AD protocol (Higher->Lower->Higher). In this case the OSPF routes will have an AD of 170 when redistributed into EIGRP. Since the AD of EIGRP external is 170 these routes will not overtake the original OSPF routes. So lower AD protocol to higher AD protocol isn’t a problem. For those who have always wondered why the external distance of EIGRP is 170 now you know ;-)

Now that we know we shouldn’t have any problems with the OSPF routes going into EIGRP we next need to consider if we’ll have any problems with EIGRP routes going into OSPF. By default EIGRP internal routes have an AD of 90 and an AD of 170 for external routes. This being the case we’ll need to consider the higher->lower->higher problem for both types of routes (internal and external). For the internal EIGRP routes there won’t be a problem since we will be going from a lower AD protocol to higher AD protocol. It’s the external EIGRP routes that weren’t originally OSPF routes. In this lab a previous task asked for the Ethernet segments (E0/0 and E0/1) on R5 to be redistributed into EIGRP. These are the routes which we will see that create the routing loop problem.

We should now be able to see what the problem is. It’s the external EIGRP routes being redistributed into OSPF and then possibly back into EIGRP. This is because we have the higher->lower->higher situation. The higher (external EIGRP) going into a lower (OSPF) and finally back into a higher (external EIGRP).

To illustrate the problem I have mutual redistribution configured between EIGRP and OSPF on both R2 and R3. We can see from the output below that R2 and R3 can not reach R5′s E0/0 interface but they can reach R5′s Loopback0 interface. The only difference is the Loopback is an internal EIGRP route while the Ethernet is an external EIGRP route. This is exactly what we expected to happen.

Rack1R2#traceroute 132.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.23.3 16 msec 17 msec 16 msec
  2 132.1.0.2 36 msec 32 msec 36 msec
  3 132.1.23.3 32 msec 32 msec 32 msec
  4 132.1.0.2 52 msec 56 msec 52 msec
  5 132.1.23.3 48 msec 48 msec 48 msec
  6 132.1.0.2 68 msec 68 msec 68 msec
  7 132.1.23.3 64 msec 68 msec 64 msec
  8 132.1.0.2 88 msec 88 msec 84 msec
  9 132.1.23.3 105 msec 96 msec 96 msec
 10 132.1.0.2 120 msec 104 msec 101 msec
Rack1R2#
Rack1R2#traceroute 150.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 150.1.5.5

  1 132.1.23.3 16 msec 16 msec 16 msec
  2 132.1.35.5 44 msec *  44 msec
Rack1R2#

Rack1R3#traceroute 132.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.0.2 28 msec 32 msec 28 msec
  2  *  *  *
  3 132.1.0.2 44 msec 48 msec 44 msec
  4  *  *  *
  5 132.1.0.2 60 msec 64 msec 64 msec
  6  *  *  *
  7 132.1.0.2 76 msec 84 msec 81 msec
  8  *  *  *
  9 132.1.0.2 269 msec 128 msec *
 10  *  *  *
Rack1R3#
Rack1R3#traceroute 150.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 150.1.5.5

  1 132.1.35.5 32 msec *  28 msec
Rack1R3#

Now that we know what the problem is we need to consider all of the possible solutions and implement the simplest solution. First off we could break this potential routing loop by just removing redistribution from R2. The output below shows the traceroutes from R2 and R3 to R5 when redistribution has been removed from R2.

Rack1R2#traceroute 150.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 150.1.5.5

  1 132.1.23.3 16 msec 16 msec 16 msec
  2 132.1.35.5 44 msec *  60 msec
Rack1R2#traceroute 132.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.0.3 28 msec 32 msec 28 msec
  2 132.1.35.5 56 msec *  56 msec
Rack1R2#

Rack1R3#traceroute 150.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 150.1.5.5

  1 132.1.35.5 28 msec *  28 msec
Rack1R3#traceroute 132.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.35.5 32 msec *  28 msec
Rack1R3#

It may seem like everything is working now but there is actually another problem that we need to resolve. R6 is not getting the external EIGRP routes originated by R5′s.

Rack1R6#show ip route 132.1.5.0
% Subnet not in table
Rack1R6#show ip route 150.1.5.0
Routing entry for 150.1.5.0/24
  Known via "eigrp 10", distance 90, metric 21154560, type internal
  Redistributing via eigrp 10
  Last update from 132.1.26.2 on FastEthernet0/0.26, 00:14:03 ago
  Routing Descriptor Blocks:
  * 132.1.26.2, from 132.1.26.2, 00:14:03 ago, via FastEthernet0/0.26
      Route metric is 21154560, traffic share count is 1
      Total delay is 45100 microseconds, minimum bandwidth is 128 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 5/255, Hops 3

Rack1R6#

So lets look back at the first router who should be receiving them and view it’s routing table.

Rack1R3#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2560512256, type external
  Redistributing via ospf 1, eigrp 10
  Advertised by ospf 1 subnets
  Last update from 132.1.35.5 on Serial1/1.1, 00:43:58 ago
  Routing Descriptor Blocks:
  * 132.1.35.5, from 132.1.35.5, 00:43:58 ago, via Serial1/1.1
      Route metric is 2560512256, traffic share count is 1
      Total delay is 20010 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 1

Rack1R3#show ip route 150.1.5.0
Routing entry for 150.1.5.0/24
  Known via "eigrp 10", distance 90, metric 20640000, type internal
  Redistributing via ospf 1, eigrp 10
  Advertised by ospf 1 subnets
  Last update from 132.1.35.5 on Serial1/1.1, 20:48:19 ago
  Routing Descriptor Blocks:
  * 132.1.35.5, from 132.1.35.5, 20:48:19 ago, via Serial1/1.1
      Route metric is 20640000, traffic share count is 1
      Total delay is 25000 microseconds, minimum bandwidth is 128 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 5/255, Hops 1

Rack1R3#

So R3 has them. Next lets go to R2 and view it’s routing table.

Rack1R2#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 64
  Last update from 132.1.0.3 on Serial0/0, 00:02:36 ago
  Routing Descriptor Blocks:
  * 132.1.0.3, from 150.1.3.3, 00:02:36 ago, via Serial0/0
      Route metric is 20, traffic share count is 1

Rack1R2#show ip route 150.1.5.0
Routing entry for 150.1.5.0/24
  Known via "eigrp 10", distance 90, metric 21152000, type internal
  Redistributing via eigrp 10
  Last update from 132.1.23.3 on Serial0/1, 21:14:51 ago
  Routing Descriptor Blocks:
  * 132.1.23.3, from 132.1.23.3, 21:14:51 ago, via Serial0/1
      Route metric is 21152000, traffic share count is 1
      Total delay is 45000 microseconds, minimum bandwidth is 128 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 5/255, Hops 2

Rack1R2#

R2 has the external EIGRP route (R5′s Ethernet0/0) as an OSPF route and the internal EIGRP route (R5′s Loopback0) still as an internal EIGRP route. This is what we expect to happen since the OSPF route has an AD of 110 and the external EIGRP route has an AD of 170. But why doesn’t R6 get the 132.1.5.0/24 route? R6 doesn’t get the route because EIGRP is not sending it due to the fact the route isn’t in the routing table as an EIGRP route. This is important to understand so let me repeat it. When EIGRP goes to send an update to it’s neighbors it selects the routes from the IP routing table and not the EIGRP topology table. This is the same behavior as RIP in that the route must be in the routing table as a RIP route or a connected route advertised by RIP before it can be sent. So what routes is EIGRP sending? It’s going to send the directly connected routes that EIGRP is advertising from the network statement under the routing process and the dynamically learned EIGRP routes in the routing table. Of course it will not send the EIGRP routes from the routing table back out the same interface they were learned on due to split horizon. So this is why the 132.1.5.0/24 route does not get advertised onto R6 even though EIGRP has the route from R3 in it’s topology table.

Rack1R2#show ip eigrp topology 132.1.5.0/24
IP-EIGRP (AS 10): Topology entry for 132.1.5.0/24
  State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295
  Routing Descriptor Blocks:
  132.1.23.3 (Serial0/1), from 132.1.23.3, Send flag is 0x0
      Composite metric is (2561024256/2560512256), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 40010 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 2
      External data:
        Originating router is 150.1.5.5
        AS number of route is 0
        External protocol is Connected, external metric is 0
        Administrator tag is 0 (0x00000000)
Rack1R2#

The goal of any solution to this problem is to ensure that the 132.1.5.0/24 route is installed into R2′s routing table as an EIGRP route. Basically there are a few standard methods we could use to achieve this goal so lets list them out:

1) Administrative distance
2) Filtering
3) Summarization

Using administrative distance there are multiple ways to resolve the problem. Below I’ve listed a few of them.

1) Change the administrative distance of the external EIGRP routes to be lower than the OSPF routes on R2.
2) Change the administrative distance of the external OSPF routes to be higher than the external EIGRP routes on R2.
3) Change the administrative distance for all of the OSPF routes to be higher than the external EIGRP routes on R2.
4) Change the administrative distance of just the OSPF routes originated by R3 on R2.
5) Change the administrative distance of just the 132.1.5.0/24 OSPF route on R2.
6) Change the administrative distance of just the 132.1.5.0/24 OSPF route originated by R3 on R2.

As we can see there are a lot of options using AD to ensure the 132.1.5.0/24 gets installed into R2′s routing table as an EIGRP route. If we were to select one of the options, option 6 would be the best. The reason 6 would be the best option is because it’s the most specific option. We normally want to select the most specific solution as we don’t want to implement a solution that could effect other routes. There are actually a couple schools of thought on this and both could be considered correct. The other way of looking at it would be to select the simplest solution regardless of what other routes it effects. Personally I prefer to select the most precise solution assuming that it’s not overly complicated.

Let’s look at what option 6 applied to R2:

Rack1R2(config)#ip access-list standard OSPF_AD
Rack1R2(config-std-nacl)#permit 132.1.5.0
Rack1R2(config-std-nacl)#router ospf 1
Rack1R2(config-router)# distance 171 150.1.3.3 0.0.0.0 OSPF_AD
Rack1R2(config-router)#^Z
Rack1R2#
Rack1R2#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2561024256, type external
  Redistributing via eigrp 10
  Last update from 132.1.23.3 on Serial0/1, 00:01:24 ago
  Routing Descriptor Blocks:
  * 132.1.23.3, from 132.1.23.3, 00:01:24 ago, via Serial0/1
      Route metric is 2561024256, traffic share count is 1
      Total delay is 40010 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 2

Rack1R2#show ip ospf database external 132.1.5.0

            OSPF Router with ID (150.1.2.2) (Process ID 1)

		Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 1513
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 132.1.5.0 (External Network Number )
  Advertising Router: 150.1.3.3
  LS Seq Number: 80000001
  Checksum: 0x6F09
  Length: 36
  Network Mask: /24
	Metric Type: 2 (Larger than any link state path)
	TOS: 0
	Metric: 20
	Forward Address: 0.0.0.0
	External Route Tag: 0

Rack1R2#

Now the route is in R2′s routing table as an EIGRP route R6 should have learned it from R2. R6 should also now be able to reach R5 E0/0.

Rack1R6#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2561026816, type external
  Redistributing via eigrp 10
  Last update from 132.1.26.2 on FastEthernet0/0.26, 00:02:08 ago
  Routing Descriptor Blocks:
  * 132.1.26.2, from 132.1.26.2, 00:02:08 ago, via FastEthernet0/0.26
      Route metric is 2561026816, traffic share count is 1
      Total delay is 40110 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 3

Rack1R6#traceroute 132.1.5.5   

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.26.2 0 msec 4 msec 4 msec
  2 132.1.23.3 16 msec 20 msec 16 msec
  3 132.1.35.5 48 msec *  44 msec
Rack1R6#

We can see that the administrative distance solution works. Now lets look at the filtering option and remove the administrative distance solution. The simplest filtering option would be to not allow R2 to install the 132.1.5.0/24 OSPF route into it’s routing table.

Rack1R2(config)#ip access-list standard OSPF_FILTER
Rack1R2(config-std-nacl)#deny 132.1.5.0
Rack1R2(config-std-nacl)#permit any
Rack1R2(config-std-nacl)#router ospf 1
Rack1R2(config-router)#distribute-list OSPF_FILTER in
Rack1R2(config-router)#^Z
Rack1R2#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2561024256, type external
  Redistributing via eigrp 10
  Last update from 132.1.23.3 on Serial0/1, 00:00:06 ago
  Routing Descriptor Blocks:
  * 132.1.23.3, from 132.1.23.3, 00:00:06 ago, via Serial0/1
      Route metric is 2561024256, traffic share count is 1
      Total delay is 40010 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 2

Rack1R2#

The next option we listed was to use summarization. Before we do that I’ll remove the distribute list and then summarize the 132.1.5.0/24 route to 132.1.4.0/23 when it’s advertised by OSPF on R3. By doing this R2 will receive the 132.1.5.0/24 via external EIGRP from R3 over the serial and the 132.1.4.0/23 via OSPF from R3 over the Frame Relay link. Since the external EIGRP route is more specific R2 will use it to reach R5′s E0/0 interface and in turn advertise the route onto R6.

Rack1R3(config)#router ospf 1
Rack1R3(config-router)#summary-address 132.1.4.0 255.255.254.0

Rack1R2#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2561024256, type external
  Redistributing via eigrp 10
  Last update from 132.1.23.3 on Serial0/1, 00:00:21 ago
  Routing Descriptor Blocks:
  * 132.1.23.3, from 132.1.23.3, 00:00:21 ago, via Serial0/1
      Route metric is 2561024256, traffic share count is 1
      Total delay is 40010 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 2

Rack1R2#show ip route 132.1.4.0
Routing entry for 132.1.4.0/23
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 64
  Last update from 132.1.0.3 on Serial0/0, 00:00:26 ago
  Routing Descriptor Blocks:
  * 132.1.0.3, from 150.1.3.3, 00:00:26 ago, via Serial0/0
      Route metric is 20, traffic share count is 1

Rack1R2#

Rack1R6#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2561026816, type external
  Redistributing via eigrp 10
  Last update from 132.1.26.2 on FastEthernet0/0.26, 00:00:39 ago
  Routing Descriptor Blocks:
  * 132.1.26.2, from 132.1.26.2, 00:00:39 ago, via FastEthernet0/0.26
      Route metric is 2561026816, traffic share count is 1
      Total delay is 40110 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 3

Rack1R6#traceroute 132.1.5.5   

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.26.2 0 msec 4 msec 0 msec
  2 132.1.23.3 16 msec 16 msec 16 msec
  3 132.1.35.5 48 msec *  44 msec
Rack1R6#

Technically we could have not allowed the 132.1.5.0/24 route from being redistributed into OSPF on R3 by filtering it with a route-map. Additionally we could have also used the “not-advertise” option on the summary command to summarize the route but not advertise. This is basically just a different way of filtering since the not-advertise option summarizes the routes but doesn’t advertise the summary.

To this point we have achieve full IP reachability but we have not met the requirements of the task. The task stated that redistribution should be done on both R2 and R3. We’ve only done it on R3. Now we need to perform redistribution on R2. We will need to implement whatever solution we used on R3 on R2.

Rack1R2(config)#router ospf 1
Rack1R2(config-router)#redistribute eigrp 10 subnets
Rack1R2(config-router)#summary-address 132.1.4.0 255.255.254.0
Rack1R2(config-router)#
Rack1R2(config-router)#router eigrp 1
Rack1R2(config-router)#redistribute ospf 1 metric 1 1 1 1 1
Rack1R2(config-router)#

We can now verify that we still have reachability from R6:

Rack1R6#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2561026816, type external
  Redistributing via eigrp 10
  Last update from 132.1.26.2 on FastEthernet0/0.26, 00:00:04 ago
  Routing Descriptor Blocks:
  * 132.1.26.2, from 132.1.26.2, 00:00:04 ago, via FastEthernet0/0.26
      Route metric is 2561026816, traffic share count is 1
      Total delay is 40110 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 3

Rack1R6#traceroute 132.1.5.5   

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.26.2 4 msec 0 msec 4 msec
  2 132.1.23.3 16 msec 16 msec 20 msec
  3 132.1.35.5 48 msec *  44 msec
Rack1R6#

We can now do a full reachabilty test to ensure everything is reachable. We will also need to do another reachabilty test when the backup link is active. Before we do that we should implement the same solution we used to stop the routing loop on R2 and R3 on R4. We do this because when the Frame Relay link between R3 and R5 is down the 132.1.5.0/24 route will be redistributed into OSPF on R4.

Rack1R4(config)#router ospf 1
Rack1R4(config-router)#redistribute eigrp 10 subnets
Rack1R4(config-router)#summary-address 132.1.4.0 255.255.254.0
Rack1R4(config-router)#
Rack1R4(config-router)#router eigrp 1
Rack1R4(config-router)#redistribute ospf 1 metric 1 1 1 1 1
Rack1R4(config-router)#

I need to add that for simplicity I only discussed the solution in regards to the 132.1.5.0/24 network but in the full solution we would need to consider the other network that is being redistributed into EIGRP on R5 (192.10.1.0/24). Also you may have noticed that the routing loop problem only occurred because a previous task asked us to redistributed the connected Ethernet interfaces into EIGRP on R5. If we would have just solved that 2 point task by advertising it natively using network statements we wouldn’t have had any routing loop problems and only lost the 2 points ;-)

Lastly you will find similar in-depth discussions added to the new IEWB-RS Volume II version 5 in regards to route redistribution. It’s important that everyone understands not only the solution we chose but what problems the solution is resolving along with any other possible solutions.

Tags: , , ,

Jul
19

The tutorial presented below is a small excerpt from the “System Management” section of beta IEWB-RS Vol I version 5.

SNMPv3 protocol a security model, defining new concepts to replace the old community-based pseudo-authentication and provide communication privacy by means of encryption. The new concepts are: user, group and security level. A group defines the access policy for a set of users. An access policy defines which SNMP objects can be accessed for reading and writing or which SNMP objects can generate notifications to the members of a group. Policy is defined by associating the respective read, write or notify view with a group. By using a notify view, a group determines the list of notifications its users can receive. A group also defines the security model and security level for its users.

Essentially, all groups form a table, which maps users to their read/write/notify views and security models. Note that if a group is defined without a read view than all objects are available to read. Contrary to that, if no write or notify view is defined, no write access is granted and no objects can send notifications to members of the group. The notify view is usually not configured manually. Rather, it’s added by the snmp-server host command automatically, when a users in a group is bound to a notification target host. Note that SNMP will use the username configured with snmp-server host along with the security model specified to authenticate and possibly encrypt the notifications. If the security model is set to «noauth» then a plain username is sent in a manner resembling the old community string.

The following security models exist: SNMPv1, SNMPv2, SNMPv3. The following security levels exits: “noAuthNoPriv” (no authentiation and no encryption – noauth keyword in CLI), “AuthNoPriv” (messages are authenticated but not encrypted – auth keyword in CLI), “AuthPriv” (messages are authenticated and encrypted – priv keyword in CLI). SNMPv1 and SNMPv2 models only support the “noAuthNoPriv” model since they use plain community string to match the incoming packets. The SNMPv3 implementations could be configured to use either of the models on per-group basis (in case if “noAuthNoPriv” is configured, username serves as a replacement for community string). All users sharing a group utilize the same security model, however, the specific model settings (password, encryption key) are sep per-user. Note that SNMPv3 does not send passwords in clear-text and uses hash-based authentication with either MD5 or SHA1 functions (HMAC authentication – the packet conted is hashed along with authentication key to produce the authentication string). For encryption, statically configured keys are used along with DES56 symmetric cipher (that mean the same key should be configured on NMS for the particular user).

Consider the example below. Three groups are created. Groups «NORMAL» and «RESTRICTED» are used to control remote users access and group «TRAP» is used to send notifications. Note that only read-view is specified for group “RESTRICTED” and it’s limited to IfEntry fields for a fixed interface index. The group «RESTRICTED» has an access-list applied to control the NMS stations the users can access from. Note that the groups have different security levels. Next, three users are created, one for each group respectively, with their authentication and encryption keys. Finally, SNMP link up and down notifications are enabled and SNMP trap destination host is configured. This operation automatically creates and assigns the «notify» view for the respective group (will appear in show commands output below).


!
! Access-List to control users in the RESTRICTED group.
!
access-list 99 permit 155.1.146.0 0.0.0.255

!
! Set ifIndexes persistent, for view definition is based on IfIndexes
!
snmp-server ifindex persist 

!
! The first view covers the “ISO” sub-branch and the second one covers
! all “lifEntry” fields for interface with IfIndex 3 (Serial 0/0).
!
snmp-server view NORMAL iso included
snmp-server view RESTRICTED ifEntry.*.3 included

!
! Define three groups. The first one allows to read and write
! into a large portion of the MIB tree. The second one allows reading
! just information specific to Serial 0/0 interface, and limits user
! access based on access-list
!
! The third group is for sending traps. A user belonging to this group
! will be utilized to send trap messages. Its name and password
! will be used to create authentication credentials in a trap message
! and the users privacy password will be used to encrypt the packet.
! Note that this group has NO notify view defined, which is done on
! on purpose. The notify view will be automatically populated when
! notification hosts are configured and bound to users
!

snmp-server group NORMAL v3 priv read NORMAL write NORMAL
snmp-server group RESTRICTED v3 auth read RESTRICTED access 99
snmp-server group TRAP v3 priv

!
! Users, their passwords and encryption keys are defined now
!
snmp-server user NORMAL NORMAL v3 auth sha CISCO priv des56 CISCO
snmp-server user RESTRICTED RESTRICTED v3 auth sha CISCO
snmp-server user TRAP TRAP v3 auth sha CISCO priv des56 CISCO

!
! Allow sending traps and configure a destination host. Note that when
! a host is configured and bound to SNMPv3 username, the corresponding
! group notify view is populated based on traps allowed for this
! particular destination. This is why it’s not required to configure
! the notify view for a group.
!
snmp-server enable traps snmp linkup linkdown
snmp-server host 155.1.146.100 traps version 3 priv TRAP

Perform some basic verifications next using the show commands. Note that SNMPv3 users do not appear in the running configuration for security reason (different management channel) but you can see some information using show snmp users command. Also, pay attention to the automatic view assigned to the “TRAP” group.

Rack1R6#show snmp user 

User name: TRAP
Engine ID: 80000009030000119221DA80
storage-type: nonvolatile	 active
Authentication Protocol: SHA
Privacy Protocol: DES
Group-name: TRAP

User name: NORMAL
Engine ID: 80000009030000119221DA80
storage-type: nonvolatile	 active
Authentication Protocol: SHA
Privacy Protocol: DES
Group-name: NORMAL

User name: RESTRICTED
Engine ID: 80000009030000119221DA80
storage-type: nonvolatile	 active
Authentication Protocol: SHA
Privacy Protocol: None
Group-name: RESTRICTED

Rack1R6#show snmp group
groupname: ILMI                             security model:v1
readview : *ilmi                            writeview: *ilmi
notifyview: 
row status: active

groupname: ILMI                             security model:v2c
readview : *ilmi                            writeview: *ilmi
notifyview: 
row status: active

groupname: TRAP                             security model:v3 noauth
readview :           writeview: 
notifyview: *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF0F
row status: active

groupname: TRAP                             security model:v3 priv
readview : v1default                        writeview: 
notifyview: 
row status: active

groupname: NORMAL                           security model:v3 priv
readview : NORMAL                           writeview: NORMAL
notifyview: 
row status: active

groupname: RESTRICTED                       security model:v3 auth
readview : RESTRICTED                       writeview: 
notifyview: 
row status: active	access-list: 99

Rack1R6#show snmp view
*ilmi system - included permanent active
*ilmi atmForumUni - included permanent active
NORMAL iso - included nonvolatile active
v1default iso - included permanent active
v1default internet.6.3.15 - excluded permanent active
v1default internet.6.3.16 - excluded permanent active
v1default internet.6.3.18 - excluded permanent active
v1default ciscoMgmt.394 - excluded permanent active
v1default ciscoMgmt.395 - excluded permanent active
v1default ciscoMgmt.399 - excluded permanent active
v1default ciscoMgmt.400 - excluded permanent active
RESTRICTED ifEntry.0.3 FF:EF included nonvolatile active
*tv.FFFFFFFF.FFFFFFFF.FFFFFFFF0F iso.2.840.10036 - included volatile active
*tv.FFFFFFFF.FFFFFFFF.FFFFFFFF0F internet - included volatile active

Tags: , , , , , , , ,

May
05

Hi Brian,

I’m having a problem with Workbook Volume 1 Version 4.1. ORF (Outbound Route Filtering) isn’t working for me. Any help would be appreciated.

Thank you,

JoeT

Hi Joe,

First off let’s talk a little bit about what BGP ORF (Outbound Route Filtering) is designed to do for us, and then we’ll take a look at some implementation examples.

From a customer’s point of view there are typically a limited amount of choices for what routes you can receive from your Service Provider via BGP. Usually the Service provider will give the customer the option of sending them a full table view (currently about 260,000 prefixes), just a default route, or some specific subset of the table such as a default route and the Service Provider’s locally originated prefixes. In other words a BGP Service Provider generally will not implement a complex outbound filtering policy for the customer. Instead, if the customer wants to receive just a subset view of the BGP table, the Customer Edge (CE) router has to filter prefixes inbound as they are received from the upstream Provider Edge (PE) router.

From the SP’s point of view this is the optimal design for administration. They don’t need to worry about change requests constantly coming from the customer about what routes they want to see and what routes they don’t want to see. Likewise from the customer’s point of view this is the optimal administrative design, as they do not need to send change control requests to the provider, and can arbitrarily change their filtering design on the fly. However from a device resource point of view this is not optimal from both the PE and CE routers’ perspective. The SP’s PE router must still send the full BGP table to the customer, even if the CE router filters out 99% of it. Likewise the CE router must still process all of the BGP UPDATE messages, even if the majority of them are ultimately filtered out.

Let’s take this a look at the result of this in the context of the following design:

AS100 — AS200
(PE) -– (CE)

AS 200 has an upstream peering to its Service Provider, AS 100. The BGP table of AS 200 appears as follows:

AS200_CE#show ip bgp
BGP table version is 12, local router ID is 10.0.0.200
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          10.0.0.100               0             0 100 i
*> 28.119.16.0/24   10.0.0.100                             0 100 54 i
*> 28.119.17.0/24   10.0.0.100                             0 100 54 i
*> 112.0.0.0        10.0.0.100                             0 100 54 50 60 i
*> 113.0.0.0        10.0.0.100                             0 100 54 50 60 i
*> 114.0.0.0        10.0.0.100                             0 100 54 i
*> 115.0.0.0        10.0.0.100                             0 100 54 i
*> 116.0.0.0        10.0.0.100                             0 100 54 i
*> 117.0.0.0        10.0.0.100                             0 100 54 i
*> 118.0.0.0        10.0.0.100                             0 100 54 i
*> 119.0.0.0        10.0.0.100                             0 100 54 i

Let’s suppose that from AS 200’s perspective the only routes that they want to receive from AS 100 are the default route plus the networks 28.119.16.0/24 and 28.119.17.0/24. Traditional filtering would dictate that on the CE router a prefix-list would be configured and applied as follows:

router bgp 200
 neighbor 10.0.0.100 remote-as 100
 neighbor 10.0.0.100 prefix-list AS_100_INBOUND in
!
ip prefix-list AS_100_INBOUND seq 5 permit 0.0.0.0/0
ip prefix-list AS_100_INBOUND seq 10 permit 28.119.16.0/24
ip prefix-list AS_100_INBOUND seq 15 permit 28.119.17.0/24

The result of this configuration in AS 200’s BGP table is as follows:

AS200_CE#show ip bgp
BGP table version is 4, local router ID is 10.0.0.200
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          10.0.0.100               0             0 100 i
*> 28.119.16.0/24   10.0.0.100                             0 100 54 i
*> 28.119.17.0/24   10.0.0.100                             0 100 54 i

Although the filtering goal is achieved, efficiency is not. From the below debug output we can see exactly how AS 200’s CE router processes the updates from the upstream PE and makes a decision on what to install:

AS200_CE#debug ip bgp updates
BGP updates debugging is on for address family: IPv4 Unicast
AS200_CE#clear ip bgp 100
%BGP-5-ADJCHANGE: neighbor 10.0.0.100 Down User reset
%BGP-5-ADJCHANGE: neighbor 10.0.0.100 Up
BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, metric 0, path 100
BGP(0): 10.0.0.100 rcvd 0.0.0.0/0
BGP(0): Revise route installing 1 of 1 routes for 0.0.0.0/0 -> 10.0.0.100(main) to main IP table
BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, path 100 54
BGP(0): 10.0.0.100 rcvd 115.0.0.0/8 -- DENIED due to: distribute/prefix-list;
BGP(0): 10.0.0.100 rcvd 114.0.0.0/8 -- DENIED due to: distribute/prefix-list;
BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, path 100 54
BGP(0): 10.0.0.100 rcvd 119.0.0.0/8 -- DENIED due to: distribute/prefix-list;
BGP(0): 10.0.0.100 rcvd 118.0.0.0/8 -- DENIED due to: distribute/prefix-list;
BGP(0): 10.0.0.100 rcvd 117.0.0.0/8 -- DENIED due to: distribute/prefix-list;
BGP(0): 10.0.0.100 rcvd 116.0.0.0/8 -- DENIED due to: distribute/prefix-list;
BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, path 100 54
BGP(0): 10.0.0.100 rcvd 28.119.17.0/24
BGP(0): 10.0.0.100 rcvd 28.119.16.0/24
BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, path 100 54 50 60
BGP(0): 10.0.0.100 rcvd 113.0.0.0/8 -- DENIED due to: distribute/prefix-list;
BGP(0): 10.0.0.100 rcvd 112.0.0.0/8 -- DENIED due to: distribute/prefix-list;
BGP(0): Revise route installing 1 of 1 routes for 28.119.16.0/24 -> 10.0.0.100(main) to main IP table
BGP(0): Revise route installing 1 of 1 routes for 28.119.17.0/24 -> 10.0.0.100(main) to main IP table
AS200_CE#

Note that the AS200_CE router generates the log message “DENIED due to: distribute/prefix-list;” for every prefix that is filtered. This means that if this were the public BGP table of 260,000+ routes this router would have to process every update message just to discard it. This is where BGP Outbound Route Filtering (ORF) comes in.

Outbound Route Filtering Capability for BGP-4 is currently an IETF draft (http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-16.txt) that describes an optimization on how prefix filtering can occur between a Customer Edge (CE) router and a Provider Edge (PE) router that are exchanging IPv4 unicast BGP prefixes. In the design we saw above the upstream PE router sent the full BGP table downstream to the CE router, and filtering was applied inbound on the downstream CE. With BGP ORF the downstream CE router dynamically tells the upstream PE router what routes to filter *outbound*. This means that the downstream CE router will only receive update messages about the prefixes that it wants.

Implementation wise the first step of this feature is for the BGP neighbors to negotiate that they both support the BGP ORF capability. Configuration-wise this looks as follows:

AS100_PE#
router bgp 100
 neighbor 10.0.0.200 remote-as 200
 !
 address-family ipv4
 neighbor 10.0.0.200 capability orf prefix-list receive
 neighbor 204.12.25.254 activate
 exit-address-family

AS200_CE#
router bgp 200
 neighbor 10.0.0.100 remote-as 100
 !
 address-family ipv4
 neighbor 10.0.0.100 capability orf prefix-list send
 neighbor 10.0.0.100 prefix-list AS_100_INBOUND in
 exit-address-family
!

The result of this configuration on AS 200’s CE is the same, however the behind the scenes mechanism by which it is accomplished is different. First, AS100_PE and AS200_CE negotiate the BGP ORF capability during initial BGP peering establishment. The success of this negotiation can be seen as follows.

AS100_PE#show ip bgp neighbors 10.0.0.200 | begin AF-dependant capabilities:
  AF-dependant capabilities:
    Outbound Route Filter (ORF) type (128) Prefix-list:
      Send-mode: received
      Receive-mode: advertised
  Outbound Route Filter (ORF): received (3 entries)
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               2          0
    Prefixes Total:                 2          0
    Implicit Withdraw:              0          0
    Explicit Withdraw:              0          0
    Used as bestpath:             n/a          0
    Used as multipath:            n/a          0

                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    ORF prefix-list:                      8        n/a
    Total:                                8          0
  Number of NLRIs in the update sent: max 4, min 2

*OUTPUT OMITTED*

AS200_CE#show ip bgp neighbors 10.0.0.100 | begin AF-dependant capabilities:
  AF-dependant capabilities:
    Outbound Route Filter (ORF) type (128) Prefix-list:
      Send-mode: advertised
      Receive-mode: received
  Outbound Route Filter (ORF): sent;
  Incoming update prefix filter list is AS_100_INBOUND
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               0          3 (Consumes 156 bytes)
    Prefixes Total:                 0          4
    Implicit Withdraw:              0          1
    Explicit Withdraw:              0          0
    Used as bestpath:             n/a          3
    Used as multipath:            n/a          0

                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Suppressed duplicate:                 0          1
    Bestpath from this peer:              3        n/a
    Total:                                3          1
  Number of NLRIs in the update sent: max 0, min 0

*OUTPUT OMITTED*

Next, AS 200’s CE router tells AS 100’s PE router which prefixes it wants to receive. The logic of this configuration is that AS 200 is “sending” a prefix-list of what routes it wants, while AS 100 is “receiving” the prefix-list of what the downstream neighbor wants. The reception of the prefix-list by the upstream PE can be verified as follows.

AS100_PE#show ip bgp neighbors 10.0.0.200 received prefix-filter
Address family: IPv4 Unicast
ip prefix-list 10.0.0.200: 3 entries
   seq 5 permit 0.0.0.0/0
   seq 10 permit 28.119.16.0/24
   seq 15 permit 28.119.17.0/24

AS100_PE#show ip prefix-list

Note that AS 100’s PE router received the list from AS 200’s CE, but the prefix-list does not show up locally in the running config. AS 100’s PE router then turns around and uses the prefix-list as an outbound filter towards the downstream CE. This can be verified two ways, by viewing the UPDATE messages on the downstream CE, and by looking at what the upstream PE is sending.

AS100_PE#show ip bgp neighbors 10.0.0.200 advertised-routes
BGP table version is 11, local router ID is 10.0.0.100
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Originating default network 0.0.0.0

   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   204.12.25.254            0             0 54 i
*> 28.119.17.0/24   204.12.25.254            0             0 54 i

Total number of prefixes 2
AS100_PE#

AS200_CE#debug ip bgp updates
BGP updates debugging is on for address family: IPv4 Unicast
AS200_CE#clear ip bgp 100
AS200_CE#
BGP(0): no valid path for 0.0.0.0/0
BGP(0): no valid path for 28.119.16.0/24
BGP(0): no valid path for 28.119.17.0/24
%BGP-5-ADJCHANGE: neighbor 10.0.0.100 Down User reset
BGP(0): nettable_walker 0.0.0.0/0 no best path
BGP(0): nettable_walker 28.119.16.0/24 no best path
BGP(0): nettable_walker 28.119.17.0/24 no best path
%BGP-5-ADJCHANGE: neighbor 10.0.0.100 Up
BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, metric 0, path 100
BGP(0): 10.0.0.100 rcvd 0.0.0.0/0
BGP(0): Revise route installing 1 of 1 routes for 0.0.0.0/0 -> 10.0.0.100(main) to main IP table
BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, path 100 54
BGP(0): 10.0.0.100 rcvd 28.119.17.0/24
BGP(0): 10.0.0.100 rcvd 28.119.16.0/24
BGP(0): Revise route installing 1 of 1 routes for 28.119.16.0/24 -> 10.0.0.100(main) to main IP table
BGP(0): Revise route installing 1 of 1 routes for 28.119.17.0/24 -> 10.0.0.100(main) to main IP table
BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, metric 0, path 100
BGP(0): 10.0.0.100 rcvd 0.0.0.0/0...duplicate ignored
AS200_CE#

Note that the above output is different from the previous debug of AS 200’s CE, because now it does not receive the extra update messages. AS 200 instead now receives only the routes that it has requested of the upstream PE.

If edits of the filter are required the downstream CE can change the prefix-list, and then through the BGP Route Refresh capability, advertise the new prefix-list upstream to the PE to be used as a new downstream filter. Configuration wise this is accomplished as follows.

AS200_CE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
AS200_CE(config)#ip prefix-list AS_100_INBOUND permit 114.0.0.0/8
AS200_CE(config)#end
AS200_CE#
%SYS-5-CONFIG_I: Configured from console by console
AS200_CE#clear ip bgp 100 in prefix-filter
AS200_CE#
BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, path 100 54
BGP(0): 10.0.0.100 rcvd 114.0.0.0/8
BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, path 100 54
BGP(0): 10.0.0.100 rcvd 28.119.17.0/24...duplicate ignored
BGP(0): 10.0.0.100 rcvd 28.119.16.0/24...duplicate ignored
BGP(0): Revise route installing 1 of 1 routes for 114.0.0.0/8 -> 10.0.0.100(main) to main IP table
BGP(0): 10.0.0.100 rcvd UPDATE w/ attr: nexthop 10.0.0.100, origin i, metric 0, path 100
BGP(0): 10.0.0.100 rcvd 0.0.0.0/0...duplicate ignored
AS200_CE#

From the “debug ip bgp updates” output we can now see that the upstream PE added the update 114.0.0.0/8, in addition to the previous three prefixes that were installed. Upstream verification on the PE also indicates this.

AS100_PE#show ip bgp neighbors 10.0.0.200 received prefix-filter
Address family: IPv4 Unicast
ip prefix-list 10.0.0.200: 4 entries
   seq 5 permit 0.0.0.0/0
   seq 10 permit 28.119.16.0/24
   seq 15 permit 28.119.17.0/24
   seq 20 permit 114.0.0.0/8
AS100_PE#show ip bgp neighbors 10.0.0.200 advertised-routes
BGP table version is 11, local router ID is 10.0.0.100
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Originating default network 0.0.0.0

   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   204.12.25.254            0             0 54 i
*> 28.119.17.0/24   204.12.25.254            0             0 54 i
*> 114.0.0.0        204.12.25.254                          0 54 i

Total number of prefixes 3
AS100_PE#

For more information on this feature:

Outbound Route Filtering Capability for BGP-4

http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-16.txt

BGP Prefix-Based Outbound Route Filtering

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ft11borf.html

Tags: , , , ,

Categories

CCIE Bloggers