First of all, let’s take a look at the testbed network we can use for this situation.

In this scenario, routers R2 and R5 represent the two ISPs. Routers R6 and R9 represent our internal network, with two subnets we need to route differently represented by Loopback interfaces Loopback9 (9.9.9.0/24 subnet) and Loopback99 (from a 99.99.99.0/24 subnet) on R9. Router R4 represents a host “somewhere” on the Internet we’ll be using for testing. We’ll pretend to have no access to change any configurations on Internet routers, so only routers R6 and R9 are available to us. Let’s see the initial configurations and clarify few things there.

Initial Network Configuration

R2:

interface GigabitEthernet0/0
 ip address 172.16.24.2 255.255.255.0
!
interface GigabitEthernet0/1
 ip address 172.16.26.2 255.255.255.0
!
router bgp 65002
 neighbor 172.16.24.4 remote-as 65004
 neighbor 172.16.26.6 remote-as 65069
 address-family ipv4
  neighbor 172.16.24.4 activate
  neighbor 172.16.24.4 send-community
  neighbor 172.16.26.6 activate
  neighbor 172.16.26.6 send-community
!

Router R4 is a dual-homed, just like our AS is. We’re using a simple configuration to prevent transit. We will apply a very similar configuration in our AS later.

R4:

interface Loopback4
 ip address 10.0.0.4 255.255.255.255
!
interface FastEthernet0/0
 ip address 172.16.24.4 255.255.255.0
!
interface FastEthernet0/1
 ip address 172.16.45.4 255.255.255.0
!
router bgp 65004
 neighbor 172.16.24.2 remote-as 65002
 neighbor 172.16.45.5 remote-as 65005
 address-family ipv4
  neighbor 172.16.24.2 activate
  neighbor 172.16.24.2 send-community
  neighbor 172.16.24.2 route-map NO-TRANSIT in
  neighbor 172.16.45.5 activate
  neighbor 172.16.45.5 send-community
  neighbor 172.16.45.5 route-map NO-TRANSIT in
  network 10.0.0.4 mask 255.255.255.255
!
route-map NO-TRANSIT permit 10
 set community no-advertise
!

R5:

interface FastEthernet0/0
 ip address 172.16.56.5 255.255.255.0
!
interface FastEthernet0/1
 ip address 172.16.45.5 255.255.255.0
!
router bgp 65005
 neighbor 172.16.45.4 remote-as 65004
 neighbor 172.16.56.6 remote-as 65069
 address-family ipv4
  neighbor 172.16.45.4 activate
  neighbor 172.16.45.4 send-community
  neighbor 172.16.56.6 activate
  neighbor 172.16.56.6 send-community
!

Similarly to the configuration on R4, we need to prevent the transit between our ISPs. However, we can’t use the “no-advertise” community here, since we need to advertise the received route(s) to R9. This is easily fixed using “no-export” community instead.

R6:

interface FastEthernet0/0
 ip address 172.16.56.6 255.255.255.0
!
interface FastEthernet0/1
 ip address 172.16.26.6 255.255.255.0
!
interface Serial0/2/0
 ip address 192.168.69.6 255.255.255.0
!
router bgp 65069
 neighbor 172.16.26.2 remote-as 65002
 neighbor 172.16.56.5 remote-as 65005
 neighbor 192.168.69.9 remote-as 65069
 address-family ipv4
  neighbor 172.16.26.2 activate
  neighbor 172.16.26.2 send-community
  neighbor 172.16.26.2 route-map NO-TRANSIT in
  neighbor 172.16.56.5 activate
  neighbor 172.16.56.5 send-community
  neighbor 172.16.56.5 route-map NO-TRANSIT in
  neighbor 192.168.69.9 activate
  neighbor 192.168.69.9 send-community
  neighbor 192.168.69.9 next-hop-self
!
route-map NO-TRANSIT permit 10
 set community no-export
!

R9:

interface Loopback9
 ip address 9.9.9.9 255.255.255.255
!
interface Loopback99
 ip address 99.99.99.99 255.255.255.255
!
interface Serial0/2/0
 ip address 192.168.69.9 255.255.255.0
!
router bgp 65069
 neighbor 192.168.69.6 remote-as 65069
 address-family ipv4
  neighbor 192.168.69.6 activate
  neighbor 192.168.69.6 send-community
  network 9.9.9.0 mask 255.255.255.0
  network 99.99.99.0 mask 255.255.255.0
!

At this point, router R9 should be able to reach Loopback4 interface advertised by R4 from its Loopback9 and Loopback99 interfaces. Let’s give it a go.

R9:

R9#ping 10.0.0.4 source Loopback9

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.4, timeout is 2 seconds:
Packet sent with a source address of 9.9.9.9
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
R9#ping 10.0.0.4 source Loopback99

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.4, timeout is 2 seconds:
Packet sent with a source address of 99.99.99.99
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

This works as expected. Now, lets’ work on our “traffic engineering”.

Chosing Different Paths from R9

Let’s say that our goal is to make the traffic between 9.9.9.0/24 and 10.0.0.0/24 take the path R9->R6->R2->R4, while the traffic between 99.99.99.0/24 needs to take the R9->R6->R5->R4 path. We can easily fix this issue using a simple policy-based routing (PBR) configuration on R6.

All we need is to match the source of traffic when it enters R6 from R9 and force it down the specific path. For example, a policy like this may do the trick.

ip access-list standard Network-9
 permit 9.9.9.0 0.0.0.255
!
ip access-list standard Network-99
 permit 99.99.99.0 0.0.0.255
!
route-map Force-Path permit 10
 match ip address Network-9
 set ip next-hop 172.16.26.2
!
route-map Force-Path permit 20
 match ip address Network-99
 set ip next-hop 172.16.56.5
!
interface Serial0/2/0
 ip policy route-map Force-Path
!

We could apply this policy and be done with it. However, there are couple of problems with this. What if the next-hop is not reachable? For example, the remote router crashes, the switch between R6 and R2/R5 drops the packets, etc? We would be black-holing the traffic. This is not a good thing in any kind of a production environment. Is there a way to solve this? As it turns out, there is. We can actually monitor the exit interface, next-hop route, as well as the next-hop itself, using object tracking. We can then have a conditional policy that will be taken into account only when all of these parameters are in place and operational. So, the policy I’m going to apply is a little bit more involved:

R6:

ip access-list standard Network-9
 permit 9.9.9.0 0.0.0.255
!
ip access-list standard Network-99
 permit 99.99.99.0 0.0.0.255
!
track 2 list boolean and
 object 21
 object 22
 object 23
!
track 5 list boolean and
 object 51
 object 52
 object 53
!
track 21 interface FastEthernet0/1 ip routing
track 22 ip route 172.16.26.0 255.255.255.0 reachability
track 23 ip sla 2
track 51 interface FastEthernet0/0 ip routing
track 52 ip route 172.16.56.0 255.255.255.0 reachability
track 53 ip sla 2
!
ip sla 2
 icmp-echo 172.16.26.2 source-ip 172.16.26.6
ip sla schedule 2 life forever start-time now
!
ip sla 5
 icmp-echo 172.16.56.5 source-ip 172.16.56.6
ip sla schedule 5 life forever start-time now
!
route-map Force-Path permit 10
 match ip address Network-9
 set ip next-hop verify-availability 172.16.26.2 10 track 2
!
route-map Force-Path permit 20
 match ip address Network-99
 set ip next-hop verify-availability 172.16.56.5 10 track 5
!
interface Serial0/2/0
 ip policy route-map Force-Path
!

That’s a lot to handle in one go. Let’s break it down a little bit. First off, I start by defining track lists. Track lists are simply multiple tracking objects that will be compared using a single boolean logic. In this case, I have three sub-objects I’m tracking and I’m combining them using “and” logic. In plain English, this means the track list will be “up” if all monitored sub-objects are “up”. The three objects are exit interface’s routing status, next-hop route and the next-hop reachability, which we monitor using IP SLA ICMP-Echo (ping) probe. Finally, it all comes together in a route-map, which uses “verify-availability” keyword to track the next-hop. Let’s see if it all works.

R6:

R6#show track 2
Track 2
  List boolean and
  Boolean AND is Up
    2 changes, last change 00:03:34
    object 21 Up
    object 22 Up
    object 23 Up
  Tracked by:
    ROUTE-MAP 0

R6#show track 5
Track 5
  List boolean and
  Boolean AND is Up
    2 changes, last change 00:03:36
    object 51 Up
    object 52 Up
    object 53 Up
  Tracked by:
    ROUTE-MAP 0

R6#show ip policy
Interface      Route map
Serial0/2/0    Force-Path

R9:

R9#traceroute 10.0.0.4 source Loopback9 

Type escape sequence to abort.
Tracing the route to 10.0.0.4

  1 192.168.69.6 0 msec 4 msec 0 msec
  2 172.16.26.2 4 msec 0 msec 0 msec
  3 172.16.24.4 4 msec *  0 msec

R9#traceroute 10.0.0.4 source Loopback99

Type escape sequence to abort.
Tracing the route to 10.0.0.4

  1 192.168.69.6 4 msec 0 msec 0 msec
  2 172.16.56.5 4 msec 0 msec 4 msec
  3 172.16.45.4 0 msec *  0 msec

This seems to be working, as we expected. What about the return traffic?

R4:

R4#traceroute 9.9.9.9 source Loopback4

Type escape sequence to abort.
Tracing the route to 9.9.9.9

  1 172.16.24.2 0 msec 0 msec 4 msec
  2 172.16.26.6 0 msec 0 msec 0 msec
  3 192.168.69.9 0 msec *  0 msec
R4#traceroute 99.99.99.99 source Loopback4

Type escape sequence to abort.
Tracing the route to 99.99.99.99

  1 172.16.24.2 0 msec 0 msec 4 msec
  2 172.16.26.6 0 msec 4 msec 0 msec
  3 192.168.69.9 0 msec *  0 msec

We can clearly see that R4 is preferring the path R4->R2->R6-?R9 for both destinations. This means that the traffic between 10.0.0.0/24 and 99.99.99.0/24 networks is taking the asymmetric route, which was one of the things we needed to avoid. Let’s handle that part now.

Chosing Different Paths from R4

Let’s not be misguided by the subtitle. Remember that R4 is just another Internet host. We can’t modify any configuration on it, yet we need to influence the decisions it makes.

Possibly the simplest solution in this case would be to take the 9.9.9.0/24 network and prepend our AS when advertising it to R5 and do the same for 99.99.99.0/24 when advertising to R2. In the lab environment, this works like a charm. In real life, all our prepending can be easily overridden with a higher local preference or a similar thing. We can only hint our preference for the incoming traffic – we cannot decide it. It would also be a very simple thing to do. I don’t like simple things, so let’s complicate our solution a little bit.

There is one thing in IP routing that trumps all weights, local preferences and as-paths of this world. It’s a rule that “more specific route always wins”. How about we use that solution for our return traffic? Let’s inject 9.9.9.0/25 and 9.9.9.128/25 towards R2, and 99.99.99.0/25 and 99.99.99.128/25 towards R5. That way, R2 will advertise more specific 9.0.0.0/24 subnets and R5 will do the same for 99.0.0.0/24. To prevent black-holing, we’ll keep advertising both original /24 routes to both R2 and R5. Let’s take a look at that solution.

R6:

ip prefix-list Network-Inject-9 seq 10 permit 9.9.9.0/25
ip prefix-list Network-Inject-9 seq 20 permit 9.9.9.128/25
!
ip prefix-list Network-Inject-99 seq 10 permit 99.99.99.0/25
ip prefix-list Network-Inject-99 seq 20 permit 99.99.99.128/25
!
ip prefix-list Network-Match-9 seq 10 permit 9.9.9.0/24
!
ip prefix-list Network-Match-99 seq 10 permit 99.99.99.0/24
!
ip prefix-list R9 seq 5 permit 192.168.69.9/32
!
route-map Inject permit 10
 set ip address prefix-list Network-Inject-9
!
route-map Inject permit 20
 set ip address prefix-list Network-Inject-99
!
route-map Match permit 10
 match ip address prefix-list Network-Match-9
 match ip route-source prefix-list R9
!
route-map Match permit 20
 match ip address prefix-list Network-Match-99
 match ip route-source prefix-list R9
!
route-map Filter-Specific-R2 deny 10
 match ip address prefix-list Network-Inject-99
!
route-map Filter-Specific-R2 permit 20
!
route-map Filter-Specific-R5 deny 10
 match ip address prefix-list Network-Inject-9
!
route-map Filter-Specific-R5 permit 20
!
router bgp 65069
 address-family ipv4
  bgp inject-map Inject exist-map Match copy-attributes
  neighbor 172.16.26.2 route-map Filter-Specific-R2 out
  neighbor 172.16.56.5 route-map Filter-Specific-R5 out
!

Again, quite a long configuration is in front of us. To solve the problem at hand, I’m using a BGP feature called “inject-map”. This feature works by referencing two route-maps, one to specify the routes to be injected and the other one to specify when these routes should be injected. In this case, my injection map is called “Inject” and the selection route-map is called “Match”. This is where simplicity ends and “IOS mind tricks” begin.

BGP inject-map feature is a tricky one. The “match” route-map must use two prefix-lists; one to match the source of the route (in our case a prefix-list called R9) and the second one to specify the routes to be considered as a condition for injection. We’re using two separate routes as triggers and for some odd reason, we must use two route-map entries to solve this problem. Each of these entries specifies a different prefix-list for the trigger route (Network-Match-9 and Network-Match-99).

The “injection” route-map works in a similar fashion. We have two-entry route-map, which uses two separate prefix-lists to inject more specific routes. These prefix-lists are Network-Inject-9 and Network-Inject-99. At this point, we should have all those more-specific routes in the BGP table on R6.

R6:

R6#show ip bgp | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*>i9.9.9.0/25       192.168.69.9             0    100      0 i
*>i9.9.9.0/24       192.168.69.9             0    100      0 i
*>i9.9.9.128/25     192.168.69.9             0    100      0 i
*> 10.0.0.4/32      172.16.26.2                            0 65002 65004 i
*                   172.16.56.5                            0 65005 65004 i
*>i99.99.99.0/25    192.168.69.9             0    100      0 i
*>i99.99.99.0/24    192.168.69.9             0    100      0 i
*>i99.99.99.128/25  192.168.69.9             0    100      0 i

The very last bit is to make sure the injected routes are advertised only to those neighbors we want them advertised to. For this purpose, I used Filter-Specific-R2 and Filter-Specific-R5 route-maps. If we examine routes received from R6 on R2 and R5, we should see a different picture on each.

R2:

R2#show ip bgp neighbors 172.16.26.6 routes | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 9.9.9.0/25       172.16.26.6                            0 65069 i
*> 9.9.9.0/24       172.16.26.6                            0 65069 i
*> 9.9.9.128/25     172.16.26.6                            0 65069 i
*> 99.99.99.0/24    172.16.26.6                            0 65069 i

Total number of prefixes 4

R5:

R5#show ip bgp neighbors 172.16.56.6 routes | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 9.9.9.0/24       172.16.56.6                            0 65069 i
*> 99.99.99.0/25    172.16.56.6                            0 65069 i
*> 99.99.99.0/24    172.16.56.6                            0 65069 i
*> 99.99.99.128/25  172.16.56.6                            0 65069 i

Total number of prefixes 4

This is exactly what I wanted to see. Last, but not the least, the routing table on R4 should also tell us that our solution worked. We’ll also confirm all this with two tracroutes.

R4:

R4#show ip route bgp
     99.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B       99.99.99.0/25 [20/0] via 172.16.45.5, 00:09:26
B       99.99.99.0/24 [20/0] via 172.16.45.5, 00:09:26
B       99.99.99.128/25 [20/0] via 172.16.45.5, 00:09:26
     9.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B       9.9.9.0/25 [20/0] via 172.16.24.2, 00:09:25
B       9.9.9.0/24 [20/0] via 172.16.45.5, 00:09:26
B       9.9.9.128/25 [20/0] via 172.16.24.2, 00:09:25

R4#traceroute 9.9.9.9 source Loopback4    

Type escape sequence to abort.
Tracing the route to 9.9.9.9

  1 172.16.24.2 0 msec 0 msec 4 msec
  2 172.16.26.6 0 msec 0 msec 0 msec
  3 192.168.69.9 0 msec *  0 msec

R4#traceroute 99.99.99.99 source Loopback4

Type escape sequence to abort.
Tracing the route to 99.99.99.99

  1 172.16.45.5 0 msec 0 msec 0 msec
  2 172.16.56.6 4 msec 0 msec 0 msec
  3 192.168.69.9 4 msec *  0 msec

There we go, a perfect solution, for a very real problem. Do you have an alternative solution to this? If you do, please post it in the comments below!

Happy studies!

–
Marko Milivojevic – CCIE #18427
Senior CCIE Instructor – IPexpert
Join our Online Study List

Print Friendly

The network in question dealt with the following diagram.

This was the task:

• Redistribute only 0.0.0.0/0 into OSPF on R2
• Make sure the default route is received in OSPF on R5 and advertised in BGP to R4

Many of you responded with the possible solutions and I’m delighted to say that the vast majority of you picked up on what was wrong with the configuration. There is more than one problem though. There are, in fact, three. Let’s examine them one by one.

OSPF Problem

Simple redistribution of the static routes will not inject the default route into OSPF domain even if there was an actual static route in place. That was of course the reason for the route not to be present in OSPF on R5. Let’s take it from there. Here’s the most relevant configuration on R2.

R2:

ip route 0.0.0.0 0.0.0.0 Null0
!
router ospf 1
 redistribute static subnets route-map Connected
!

Even though there is a route-map attached, it was configured in such a way to permit the default route. As we’ve established, this route never made it to the OSPF.

R2:

R2#show ip ospf database external

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

In order to install the default route, we’ll need to use the “default-information originate” command under the OSPF process.

R2:

router ospf 1
 default-information originate
!

Things are now looking much better on R5, since we’ll see the default route in OSPF.

R5:

R5#show ip route ospf
     192.168.0.0/32 is subnetted, 2 subnets
O       192.168.0.2 [110/65] via 192.168.25.2, 00:58:43, Serial0/2/0
O*E2 0.0.0.0/0 [110/1] via 192.168.25.2, 00:01:11, Serial0/2/0

There is something I’m not telling you right now, but we’re not on a very good path. I’ll come back here later on.

BGP Problem

Let’s take a look at the second part of the problem, which is advertising the default route to R4 over the BGP session. Even though we’re redistributing the OSPF routes into BGP, the default route is not making it.

R5:

router bgp 5
 redistribute ospf 1
 neighbor 172.16.45.4 remote-as 4
!

There are two reasons for this behavior. The first one is somewhat obscure behavior of BGP and OSPF interaction, which is the fact that when redistributing the routes form OSPF into BGP, only internal OSPF routes will be redistributed by default. To test this, we’ll quickly remove the route-map from the redistribution on R2. This should cause our other static route from R2 to be advertised into OSPF.

R2:

ip route 10.0.0.0 255.0.0.0 Null0
!
router ospf 1
 no redistribute static subnets route-map Connected
 redistribute static subnets
!

Let’s check the routing and BGP tables on R5.

R5:

R5#show ip route ospf
O E2 10.0.0.0/8 [110/20] via 192.168.25.2, 00:01:09, Serial0/2/0
     192.168.0.0/32 is subnetted, 2 subnets
O       192.168.0.2 [110/65] via 192.168.25.2, 01:07:25, Serial0/2/0
O*E2 0.0.0.0/0 [110/1] via 192.168.25.2, 00:09:54, Serial0/2/0

R5#show ip bgp | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.0.2/32   192.168.25.2            65         32768 ?
*> 192.168.0.5/32   0.0.0.0                  0         32768 ?
*> 192.168.25.0     0.0.0.0                  0         32768 ?

As we can see, 10.0.0.0/8 route didn’t make it into the BGP and neither did the default route. Let’s configure BGP to take external routes into account in addition to the internal routes.

R5:

router bgp 5
 redistribute ospf 1 match internal external
!

R5#show ip bgp | begin Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0         192.168.25.2            20         32768 ?
*> 192.168.0.2/32   192.168.25.2            65         32768 ?
*> 192.168.0.5/32   0.0.0.0                  0         32768 ?
*> 192.168.25.0     0.0.0.0                  0         32768 ?

We can now see that 10.0.0.0/8 route made it into the BGP, but the default route is still missing. This brings us to the real problem. Similarly to OSPF when redistributing the routes into BGP, IOS will not consider the default route as the valid route for redistribution, unless we tell it explicitly.

There are several ways to do that, but I will use the solution suggested by most of the readers in the previous article (democracy wins), which is a “neighbor default-originate” command.

R5:

router bgp 5
 neighbor 192.168.45.4 default-originate
!

R4:

R4#show ip route bgp
B    192.168.25.0/24 [20/0] via 172.16.45.5, 01:14:22
B    10.0.0.0/8 [20/20] via 172.16.45.5, 00:04:40
     192.168.0.0/32 is subnetted, 2 subnets
B       192.168.0.2 [20/65] via 172.16.45.5, 01:14:22
B       192.168.0.5 [20/0] via 172.16.45.5, 01:14:53
B*   0.0.0.0/0 [20/1] via 172.16.45.5, 00:00:55

That’s it, problem solved! Well… not so fast.

The Devil is in the Details

Let’s remind ourselves again of the original task. I don’t like repeating myself repeating myself, repeating … but bear with me here.

• Redistribute only 0.0.0.0/0 into OSPF on R2
• Make sure the default route is received in OSPF on R5 and advertised in BGP to R4

We have certainly accomplished the task, as instructed, since we have the default route on R5 and on R4. What would happen though if I removed the default route from R2?

R2:

no ip route 0.0.0.0 0.0.0.0 Null0

R5:

R5#show ip route ospf
O E2 10.0.0.0/8 [110/20] via 192.168.25.2, 00:15:04, Serial0/2/0
     192.168.0.0/32 is subnetted, 2 subnets
O       192.168.0.2 [110/65] via 192.168.25.2, 01:21:20, Serial0/2/0

Obviously, it will be gone from OSPF and not available on R5. What about R4?

R4:

R4#show ip route bgp
B    192.168.25.0/24 [20/0] via 172.16.45.5, 00:02:00
B    10.0.0.0/8 [20/20] via 172.16.45.5, 00:02:00
     192.168.0.0/32 is subnetted, 2 subnets
B       192.168.0.2 [20/65] via 172.16.45.5, 00:02:00
B       192.168.0.5 [20/0] via 172.16.45.5, 00:02:00
B*   0.0.0.0/0 [20/0] via 172.16.45.5, 00:02:00

Where did that default route come from? It was generated by R5 to R4, even though R5 never had it in the routing table.

As many of you correctly stated in the previous article’s comments, there are multiple ways of generating the default route in BGP. Other methods include:

• Redistribute the original source protocol and using “default-information originate”
• Aggregate the prefixes using “aggregate-address”
• Use the “network” statement

Any of these methods would be useful and as always when dealing with the CCIE lab, you should probably use one that requires the least amount of work and produces the least amount of side effects. The easiest solution to use is the “network” statement. If we opt for “default-information originate”, we’ll need to redistribute OSPF into the BGP and that causes other routes to be advertised, too. If we use the aggregate-address, we’ll generate the default route if any route is present in the BGP table, unless we use conditional advertising. None of these are as easy as a simple “network” command. So, let’s change our configuration, but don’t forget to put the original static default back in.

R2:

ip route 0.0.0.0 0.0.0.0 Null0

R5:

router bgp 5
 no neighbor 172.16.45.4 default-originate
 no redistribute ospf 1
 network 0.0.0.0 mask 0.0.0.0
!

The beauty of this solution is that only the default route will be advertised to R4 as the result of the OSPF configuration on R2 and no other routes.

R4:

R4#show ip route bgp
B*   0.0.0.0/0 [20/1] via 172.16.45.5, 00:01:26

For testing purpose, let’s remove the static route on R2 and see what happens.

R2:

no ip route 0.0.0.0 0.0.0.0 Null0

R4#show ip route bgp

Brilliant, but we’re not quite done yet. We have now established the correct relationship between BGP and OSPF on R5. How about the relationship between the static routes and OSPF on R2, the very origin of our routes?

We clearly saw what happens when we add or remove the static routes. We can see them being added and removed as a part of our redistribution process. We did have a requirement to redistribute only the default route and no other routes. Our original solution was to use the “redistribute static subnets route-map” command. There is no need for it though.

One Step Further

I should point out that we’re now entering the exercise zone. What follows was never a requirement of the original task, but it’s an interesting behavior and those are always fun to explore, if only a little bit.

When we configured “default-information originate” under the OSPF process, we configured an implicit redistribution of the 0.0.0.0/0 route from whatever source it came from. As it is, the default route could come from any valid source on R2! If we removed the static and we learned the default from EIGRP, R2 would still advertise the default route into OSPF. Can we actually solve the task in such a way to cause the injection of the default route in OSPF only if the original route came from the static route? The answer is – not really, but we can get very close to it.

It’s not a very straight-forward solution, but it can work. As a food for thought, I’ll leave it up to you to discuss why I did it this way and not some other way.

R2:

no ip route 0.0.0.0 0.0.0.0 Null0
ip route 192.0.2.1 255.255.255.255 Null0
ip route 0.0.0.0 0.0.0.0 192.0.2.1
!
access-list 10 permit host 0.0.0.0
access-list 11 permit host 192.0.2.1
!
route-map Static-Only permit 10
 match ip address 10
 match ip next-hop 11
!
router ospf 1
 no redistribute static
 default-information originate route-map Static-Only
!

Happy studies!

–
Marko Milivojevic – CCIE #18427
Senior CCIE Instructor – IPexpert
Join our Online Study List

Print Friendly

Couple of days ago, a student sent me this little problem. It looks simple, but let’s see how you do solving it.

The setup is really straight-forward. Routers R2 and R5 are running OSPF in area 0. Router R2 has two static routes pointing to Null0 interface (0.0.0.0/0 and 10.0.0.0/8). This is the task:

• Redistribute only 0.0.0.0/0 into OSPF on R2
• Make sure the default route is received in OSPF on R5 and advertised in BGP to R4

Here is the relevant configuration on all three routers.

R2:

hostname R2
!
interface Loopback0
 ip address 192.168.0.2 255.255.255.255
!
interface Serial0/2/0
 ip address 192.168.25.2 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 Null0
ip route 10.0.0.0 255.0.0.0 Null0
!
ip prefix-list Redistribute seq 10 permit 0.0.0.0/0
!
route-map Connected permit 10
 match ip address prefix-list Redistribute
!
router ospf 1
 router-id 192.168.0.2
 network 192.168.0.0 0.0.255.255 area 0
 redistribute static subnets route-map Connected
!

R5:

hostname R5
!
interface Loopback0
 ip address 192.168.0.5 255.255.255.255
!
interface Serial0/0/0
 ip address 172.16.45.5 255.255.255.0
!
interface Serial0/2/0
 ip address 192.168.25.5 255.255.255.0
!
router ospf 1
 router-id 192.168.0.5
 network 192.168.0.0 0.0.255.255 area 0
!
router bgp 5
 bgp router-id 192.168.0.5
 neighbor 172.16.45.4 remote-as 4
 redistribute ospf 1
!

R4:

hostname R4
!
interface Loopback0
 ip address 172.16.0.4 255.255.255.255
!
interface Serial0/1/0
 ip address 172.16.45.4 255.255.255.0
!
router bgp 4
 bgp router-id 172.16.0.4
 neighbor 172.16.45.5 remote-as 5
!

We can see that both OSPF and BGP are operational:

R5:

R5#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.0.2       0   FULL/  -        00:00:34    192.168.25.2    Serial0/2/0

R5#show ip bgp summary | begin ^Neighbor
Neighbor        V          AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.45.4     4          4      31      33        4    0    0 00:29:56        0

However, not everything works as expected. Take a look at the OSPF routes on R5:

R5:

R5#show ip route ospf
     192.168.0.0/32 is subnetted, 2 subnets
O       192.168.0.2 [110/65] via 192.168.25.2, 00:31:28, Serial0/2/0

Also, let’s take a look at the BGP routes on R4:

R4:

R4#show ip route bgp
B    192.168.25.0/24 [20/0] via 172.16.45.5, 00:30:00
     192.168.0.0/32 is subnetted, 2 subnets
B       192.168.0.2 [20/65] via 172.16.45.5, 00:30:00
B       192.168.0.5 [20/0] via 172.16.45.5, 00:30:00

We can clearly see that the default route is missing on both R5 and R4. What’s wrong and how do we fix this problem? Post your thoughts and solutions in the comments below and in a few days, I’ll follow-up with the solution.

Happy studies!

–
Marko Milivojevic – CCIE #18427
Senior CCIE Instructor – IPexpert
Join our Online Study List

Print Friendly

The biggest challenge when dealing with these kinds of attacks is detecting where they are coming from. In some networks, there are more than a few ingress points and there could be hundreds or even thousands of source addresses participating in the attack. Digesting this information and compiling the exact information takes time. During this time, not only the targets (victims) are suffering, but entire network infrastructure is under stress. In a case of service provider and carrier networks, customers other than those under direct attack may be affected. In other words, collateral damage during the attack investigation can be devastating. It is sometime necessary to “sacrifice” the intended victim, while ensuring the rest of the infrastructure and other customers are relatively unaffected by the attack.

When the infrastructure is protected and stabilized, investigation can take full force and original sources of the attack identified and prevented from further denial of service attack at the intended target.

What I described above are the guiding ideas between two types of DoS protection mechanisms using remote triggered black hole filtering, also known in the industry as RTBH filtering. These two types are destination and source based RTBH filtering.

Here are some brief characteristics of both.

• Destination Based RTBH:
  • Requires knowledge of the target (victim) address/network.
  • Willingly sacrifices (black-holes) the communication of the target with the rest of the world.
  • Relies on BGP to “signal” black-hole from trigger to one or more enforcers – usually edge (border) routers in the network.
  • Uses unreachable next-hop to drop packets to the destination.
• Source-Based RTBH:
  • Requires knowledge of the attack source/sources.
  • Attack sources are unable to communicate with the entire protected infrastructure, not only the intended victims.
  • Relies on BGP to “signal” black-hole from trigger to one or more enforcers – usually edge (border) routers in the network.
  • Uses Unicast Reverse Path Forwarding (uRPF) to drop packets.

Test Network

In order to properly test both kinds of RTBH, we will use the following network.

On the diagram above, R1 will represent the Internet. Two Loopbacks will represent “good” traffic (1.1.1.1) and “evil” traffic (11.11.11.11). Target/victim host resides on R6 and is represented by a loopback interface with the address 6.6.6.6. R2 and R4 are border routers in AS2456 and they peer with R1. R5 will have multiple roles in this scenario, as we’ll see.

For the initial configuration, we’ll use the following configurations on all involved routers. I will show only relevant bits.

R1:

interface Loopback1
 ip address 1.1.1.1 255.255.255.255
!
interface Loopback11
 ip address 11.11.11.11 255.255.255.255
!
ip bgp-community new-format
!
router bgp 1
 network 1.1.1.1 mask 255.255.255.255
 network 11.11.11.11 mask 255.255.255.255
 neighbor 172.16.12.2 remote-as 2456
 neighbor 172.16.12.2 send-community
 neighbor 172.16.14.4 remote-as 2456
 neighbor 172.16.14.4 send-community
!

R2:

router ospf 1
 network 192.168.0.0 0.0.255.255 area 0
!
ip bgp-community new-format
!
router bgp 2456
 neighbor 172.16.12.1 remote-as 1
 neighbor 172.16.12.1 send-community
 neighbor 192.168.0.4 remote-as 2456
 neighbor 192.168.0.4 update-source Loopback0
 neighbor 192.168.0.4 next-hop-self
 neighbor 192.168.0.4 send-community
 neighbor 192.168.0.5 remote-as 2456
 neighbor 192.168.0.5 update-source Loopback0
 neighbor 192.168.0.5 next-hop-self
 neighbor 192.168.0.5 send-community
 neighbor 192.168.0.6 remote-as 2456
 neighbor 192.168.0.6 update-source Loopback0
 neighbor 192.168.0.6 next-hop-self
 neighbor 192.168.0.6 send-community
!

R4:

router ospf 1
 network 192.168.0.0 0.0.255.255 area 0
!
ip bgp-community new-format
!
router bgp 2456
 neighbor 172.16.14.1 remote-as 1
 neighbor 172.16.14.1 send-community
 neighbor 192.168.0.2 remote-as 2456
 neighbor 192.168.0.2 update-source Loopback0
 neighbor 192.168.0.2 next-hop-self
 neighbor 192.168.0.2 send-community
 neighbor 192.168.0.5 remote-as 2456
 neighbor 192.168.0.5 update-source Loopback0
 neighbor 192.168.0.5 next-hop-self
 neighbor 192.168.0.5 send-community
 neighbor 192.168.0.6 remote-as 2456
 neighbor 192.168.0.6 update-source Loopback0
 neighbor 192.168.0.6 next-hop-self
 neighbor 192.168.0.6 send-community
!

R5:

router ospf 1
 network 192.168.0.0 0.0.255.255 area 0
!
ip bgp-community new-format
!
router bgp 2456
 neighbor 192.168.0.2 remote-as 2456
 neighbor 192.168.0.2 update-source Loopback0
 neighbor 192.168.0.2 send-community
 neighbor 192.168.0.4 remote-as 2456
 neighbor 192.168.0.4 update-source Loopback0
 neighbor 192.168.0.4 send-community
 neighbor 192.168.0.6 remote-as 2456
 neighbor 192.168.0.6 update-source Loopback0
 neighbor 192.168.0.6 send-community
!

R6:

interface Loopback6
 ip address 6.6.6.6 255.255.255.255
!
router ospf 1
 log-adjacency-changes
 network 192.168.0.0 0.0.255.255 area 0
!
ip bgp-community new-format
!
router bgp 2456
 network 6.6.6.6 mask 255.255.255.255
 network 192.168.0.6 mask 255.255.255.255
 neighbor 192.168.0.2 remote-as 2456
 neighbor 192.168.0.2 update-source Loopback0
 neighbor 192.168.0.2 send-community
 neighbor 192.168.0.4 remote-as 2456
 neighbor 192.168.0.4 update-source Loopback0
 neighbor 192.168.0.4 send-community
 neighbor 192.168.0.5 remote-as 2456
 neighbor 192.168.0.5 update-source Loopback0
 neighbor 192.168.0.5 send-community
!

We can see in the above configurations that we are dealing with relatively simple iBGP full mesh configuration with OSPF as IGP in AS2456 and there is eBGP peering between edge routers. Router R1 is advertising its interfaces Loopback1 and Loopback11, while R6 is advertising Loopback0 and Loopback6. These should be visible and reachable from each other. Let’s make sure they are before we proceed!

R1:

R1#show ip route bgp
     6.0.0.0/32 is subnetted, 1 subnets
B       6.6.6.6 [20/0] via 172.16.12.2, 01:49:54
     192.168.0.0/32 is subnetted, 1 subnets
B       192.168.0.6 [20/0] via 172.16.12.2, 01:49:54

R1#ping 6.6.6.6 source Loopback1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R1#ping 6.6.6.6 source Loopback11

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
R1#ping 192.168.0.6 source Loopback1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.6, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
R1#ping 192.168.0.6 source Loopback11

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.6, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

We don’t need to verify anything on R6, but I will just briefly show you the BGP table there.

R6:

R6#show ip bgp
BGP table version is 14, local router ID is 192.168.0.6
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
* i1.1.1.1/32       192.168.0.4              0    100      0 1 i
*>i                 192.168.0.2              0    100      0 1 i
*> 6.6.6.6/32       0.0.0.0                  0         32768 i
* i11.11.11.11/32   192.168.0.4              0    100      0 1 i
*>i                 192.168.0.2              0    100      0 1 i
*> 192.168.0.6/32   0.0.0.0                  0         32768 i

RTBH Signaling Infrastructure

As I mentioned in the introduction, RTBH relies on BGP for signaling. I neglected to mention what kind of signaling that is. When we decide that certain traffic needs to be discarded by edge routers, we need to let them know that. The simplest method is to advertise the route from one of the BGP routers in our network with a certain community attached. When edge routers receive the route with a community of our choice attached, they can then take steps to discard the traffic. Let’s put this in motion. Our signaling router will be R6.

Please note: Any router in the network can be the “trigger” router. My choice of R6 versus R5 is because I will later use R5 to illustrate couple of caveats with RTBH implementation.

Signaling router will be configured to attach a black-hole community to static routes tagged with a specific tag. You are free to choose any values. In this example I will use static tag “2456″ that will translate to BGP community “2456:2456″. Here is the configuration.

R6:

route-map RTBH-Trigger permit 10
 match tag 2456
 set community 2456:2456
!
route-map RTBH-Trigger permit 99
!
router bgp 2456
 redistribute static route-map RTBH-Trigger
!

To test the solution, let’s add two static routes pointing to Null0 on R6. One will be 192.168.6.1/32 with tag 2456 and the other one 192.168.6.2/32 without a tag. We will then observe what happens in BGP.

R6:

ip route 192.168.6.1 255.255.255.255 Null0 tag 2456
ip route 192.168.6.2 255.255.255.255 Null0

Let’s take a look at R1.

R1:

R1#show ip bgp
BGP table version is 6, local router ID is 172.16.0.1
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
*> 1.1.1.1/32       0.0.0.0                  0         32768 i
*  6.6.6.6/32       172.16.14.4                            0 2456 i
*>                  172.16.12.2                            0 2456 i
*> 11.11.11.11/32   0.0.0.0                  0         32768 i
*  192.168.0.6/32   172.16.14.4                            0 2456 i
*>                  172.16.12.2                            0 2456 i
*  192.168.6.1/32   172.16.14.4                            0 2456 ?
*>                  172.16.12.2                            0 2456 ?

We are receiving both of these routes. While this is perfectly OK when we are using Null0 routes to inject prefixes into BGP, we need to ensure that RTBH signaling routes do not “leak” into neighboring autonomous systems – unless, of course, we use inter-AS signaling for RTBH, which is not something I will touch on today. The easiest way to prevent leaks is to ensure that trigger routes are not exported outside our own autonomous system, using well-known “no-export” community.

R1:

route-map RTBH-Trigger permit 10
 match tag 2456
 set community 2456:2456 no-export
!

Let’s verify the status on R1 again.

R1:

R1#show ip bgp
BGP table version is 9, local router ID is 172.16.0.1
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
*> 1.1.1.1/32       0.0.0.0                  0         32768 i
*  6.6.6.6/32       172.16.14.4                            0 2456 i
*>                  172.16.12.2                            0 2456 i
*> 11.11.11.11/32   0.0.0.0                  0         32768 i
*  192.168.0.6/32   172.16.14.4                            0 2456 i
*>                  172.16.12.2                            0 2456 i
*  192.168.6.2/32   172.16.14.4                            0 2456 ?
*>                  172.16.12.2                            0 2456 ?

We can see that now only the 2nd route is present on R1. Let’s see R2.

R2:

R2#show ip bgp
BGP table version is 17, local router ID is 192.168.0.2
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
* i1.1.1.1/32       192.168.0.4              0    100      0 1 i
*>                  172.16.12.1              0             0 1 i
*>i6.6.6.6/32       192.168.0.6              0    100      0 i
* i11.11.11.11/32   192.168.0.4              0    100      0 1 i
*>                  172.16.12.1              0             0 1 i
r>i192.168.0.6/32   192.168.0.6              0    100      0 i
*>i192.168.6.1/32   192.168.0.6              0    100      0 ?
*>i192.168.6.2/32   192.168.0.6              0    100      0 ?
R2#show ip bgp 192.168.6.1
BGP routing table entry for 192.168.6.1/32, version 16
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
Flag: 0x880
  Not advertised to any peer
  Local
    192.168.0.6 (metric 66) from 192.168.0.6 (192.168.0.6)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Community: 2456:2456 no-export
R2#show ip bgp 192.168.6.2
BGP routing table entry for 192.168.6.2/32, version 17
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
        1
  Local
    192.168.0.6 (metric 66) from 192.168.0.6 (192.168.0.6)
      Origin incomplete, metric 0, localpref 100, valid, internal, best

With that verified, we can remove our test routes from R6.

R6:

no ip route 192.168.6.1 255.255.255.255 Null0 tag 2456
no ip route 192.168.6.2 255.255.255.255 Null0

Our signaling is now ready. The next step is to actually implement traffic drop. This is where things become somewhat different for destination-based and source-based RTBH. We will explore them separately.

Destination-Based RTBH

With destination-based black-hole we will be dropping the traffic going TO a particular destination. Therefore, our trigger router needs to indicate this. Our test destination (victim) is the Loopback6 on R6. Since this is directly connected interface on R6, we can’t use the static route as in the previous example, but we can simply add the community to the advertisement.

R6:

route-map Loopback6-RTBH
 set community 2456:2456
!
router bgp 2456
 network 6.6.6.6 mask 255.255.255.255 route-map Loopback6-RTBH
!

We can now see that on R2 and R4 6.6.6.6/32 is received with the community.

R2:

R2#show ip bgp 6.6.6.6
BGP routing table entry for 6.6.6.6/32, version 20
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x880
  Advertised to update-groups:
        1
  Local
    192.168.0.6 (metric 66) from 192.168.0.6 (192.168.0.6)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: 2456:2456

Those with sharp eyes probably noticed that I didn’t add no-export. The reason for that is that 6.6.6.6/32 is considered to be part of AS2456. It’s perfectly OK to have it advertised to the outside world, even with the additional community set. At this moment we also want R1 to have the reachability to R6 so we can test if our black hole works. We will remove this route later on.

That said, we now have the route, again, but what do we do with it? Remember, the idea here is to drop the traffic going to this destination. In order to accomplish this task, we will need to somehow redirect the traffic on our enforcing routers (R2 and R4) and instead of sending it towards R6, drop it. We can do that by changing the next-hop attribute in BGP.

Next-hop is mandatory BGP attribute. We can see in the output above that next-hop for 6.6.6.6 is 192.168.0.6. To implement the drop, we will have to use a single Null0 static route and an imaginary address for next-hop. The usual address used for this purpose is part of the official test network, as defined by RFC-1918. This is any address from 192.0.2.0/24 subnet. I will use 192.0.2.1/32 and here is how.

R2 and R4:

ip route 192.0.2.1 255.255.255.255 Null0
!
ip community-list standard RTBH-Trigger permit 2456:2456
!
route-map UseRTBH permit 10
 match community RTBH-Trigger
 set ip next-hop 192.0.2.1
!
route-map UseRTBH permit 99
!
router bgp 2456
 neighbor 192.168.0.6 route-map UseRTBH in
!

What I did there is I created a route-map to apply in the input direction from R6 on R2 and R4. This route-map will match the trigger community and for those routes that match, set the next-hop to 192.0.2.1. Unless I have static route (or other source) for this next-hop, route would be invalid. However, I do not want the route to be invalid, because then some other route, possible less-specific, route can take the traffic. What I want is the trigger route to be considered the best, so I can explicitly drop the traffic for the destination.

Let’s see if this works. First off, let’s see the next hop on R2.

R2:

R2#show ip bgp 6.6.6.6
BGP routing table entry for 6.6.6.6/32, version 23
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
        1
  Local
    192.0.2.1 from 192.168.0.6 (192.168.0.6)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: 2456:2456

This worked. Let’s see the ping from R1.

R1:

R1#ping 6.6.6.6 source Loopback11

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
U.U.U
Success rate is 0 percent (0/5)
R1#ping 192.168.0.6 source Loopback11

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.6, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

We can see that from R1 we cannot ping Loopback6 on R6, but we can easily access Loopback0. If Loopback6 was under attack, this would cause traffic to that destination to be dropped by R2 and R4, adding no additional workload for R5 and R6. However… there is one minor problem. You can see that border routers are generating ICMP unreachable messages. This is causing more work for them and increases their CPU load. One can be tempted to simply disable ICMP unreachable messages on interfaces facing R1, but that can break legitimate things like Path MTU Discovery. What we need is a way to stop sending unreachables for traffic redirected to Null0 interface. You may be surprised how easily that is done.

R2 and R4:

interface Null0
 no ip unreachables
!

Let’s test again from R1.

R1:

R1#ping 6.6.6.6 source Loopback11

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
.....
Success rate is 0 percent (0/5)

Much better. Still, we’re indiscriminately dropping the traffic going to 6.6.6.6. Let’s see what we can do when we figure out who the attacker is.

Source-Based RTBH

We discovered that source of our attack is 11.11.11.11/32. We can now implement source-based RTBH. Method is very similar to the one used just before, except that we signal with the static route for 11.11.11.11/32 on R6. I will now remove the community from 6.6.6.6 and add the trigger for 11.11.11.11/32.

R6:

router bgp 2456
 no network 6.6.6.6 mask 255.255.255.255 route-map Loopback6-RTBH
 network 6.6.6.6 mask 255.255.255.255
!
ip route 11.11.11.11 255.255.255.255 Null0 tag 2456

Since our infrastructure is already in place, we should see this prefix with the next-hop of 192.0.2.1 on R2.

R2:

R2#show ip bgp 11.11.11.11
BGP routing table entry for 11.11.11.11/32, version 28
Paths: (2 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
Flag: 0x820
  Not advertised to any peer
  Local
    192.0.2.1 from 192.168.0.6 (192.168.0.6)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Community: 2456:2456 no-export
  1
    172.16.12.1 from 172.16.12.1 (172.16.0.1)
      Origin IGP, metric 0, localpref 100, valid, external

If I ping from Loopback11 of R1, no traffic should be reaching R6, while ping from Loopback1 should work. Let’s try.

R1:

R1#ping 6.6.6.6 source Loopback11

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
.....
Success rate is 0 percent (0/5)
R1#ping 6.6.6.6 source Loopback1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

This seems to work… or does it? Let’s enable some debug on R6 and re-run the ping.

R6:

access-list 100 permit icmp any any echo
access-list 100 permit icmp any any echo-reply

R6#debug ip packet 100

R1:

R1#ping 6.6.6.6 source Loopback11 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
.
Success rate is 0 percent (0/1)

R6:

 IP: s=11.11.11.11 (FastEthernet0/0), d=6.6.6.6, len 100, input feature, MCI Check(64), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
 IP: tableid=0, s=11.11.11.11 (FastEthernet0/0), d=6.6.6.6 (Loopback6), routed via RIB
 IP: s=11.11.11.11 (FastEthernet0/0), d=6.6.6.6, len 100, rcvd 4
 IP: s=11.11.11.11 (FastEthernet0/0), d=6.6.6.6, len 100, stop process pak for forus packet
 IP: s=6.6.6.6 (local), d=11.11.11.11 (Null0), len 100, sending

We can see that R1 is not getting any responses, but R6 is still getting the traffic! We have NOT stopped the DoS attack. To do so, we need to verify if the source of the traffic is valid. We will use uRPF feature as mentioned earlier. To be more precise, we will use loose uRPF, which will only verify if the route to the destination is valid. Null0 route is not considered valid and uRPF will fail. Let’s configure that on R2 and R4 facing R1.

R2:

interface GigabitEthernet0/1
 ip verify unicast source reachable-via any
!

R4:

interface FastEthernet0/0
 ip verify unicast source reachable-via any
!

When we re-run the ping from R1, we should see no debugging output on R6. We have now stopped the attack from 11.11.11.11! There are still few possible design-related issues.

Partial Implementation Caveats

What happens in a case that for example filtering is done only by R2, but not R4? If the traffic reached R4, it would reach R5 and ultimately R6. One way to prevent this issue from happening is to force the next-hop change on the trigger router itself. In our case this is on R6. If we decide to go with that option, we may be creating yet another problem, which is not immediately obvious. Let’s change our network so that R5 is the route-reflector, with R2, R4 and R6 being clients. I will also change where the next-hop is changed. Here is the configuration.

R2:

router bgp 2456
 no neighbor 192.168.0.4
 no neighbor 192.168.0.6
!

R4:

router bgp 2456
 no neighbor 192.168.0.2
 no neighbor 192.168.0.6
!

R5:

router bgp 2456
 neighbor 192.168.0.2 route-reflector-client
 neighbor 192.168.0.4 route-reflector-client
 neighbor 192.168.0.6 route-reflector-client
!

R6:

ip route 192.0.2.1 255.255.255.255 Null0
!
ip community-list standard RTBH-Trigger permit 2456:2456
!
route-map SetNH permit 10
 match community RTBH-Trigger
 set ip next-hop 192.0.2.1
!
route-map SetNH permit 99
!
router bgp 2456
 no neighbor 192.168.0.2
 no neighbor 192.168.0.4
 neighbor 192.168.0.5 route-map SetNH out
!

Let’s see the trigger route on R5.

R5:

R5#show ip bgp 11.11.11.11
BGP routing table entry for 11.11.11.11/32, version 62
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
Flag: 0x800
  Advertised to update-groups:
        2
  Local, (Received from a RR-client)
    192.0.2.1 (metric 2) from 192.168.0.6 (192.168.0.6)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Community: 2456:2456 no-export

How can the route be valid, when there is no valid next-hop? Or is there a valid next-hop?

R5:

R5#show ip route 192.0.2.1
Routing entry for 192.0.2.1/32
  Known via "bgp 2456", distance 200, metric 0, type internal
  Last update from 192.168.0.6 00:01:20 ago
  Routing Descriptor Blocks:
  * 192.168.0.6, from 192.168.0.6, 00:01:20 ago
      Route metric is 0, traffic share count is 1
      AS Hops 0

Router R6 is advertising the 192.0.2.1 route, which means that it may still attract the traffic if only one of the border routers are misconfigured! To fix this issue, we must prevent this route from being advertised by R6. Even more filtering!

R6:

ip prefix-list NO-TRIGGER permit 192.0.2.0/24 le 32
!
route-map RTBH-Trigger deny 20
 match ip address prefix-list NO-TRIGGER
!

Now, the situation on R5 is completely different.

R5:

R5#show ip bgp 11.11.11.11
BGP routing table entry for 11.11.11.11/32, version 67
Paths: (3 available, best #3, table Default-IP-Routing-Table)
  Advertised to update-groups:
        2
  Local, (Received from a RR-client)
    192.0.2.1 (inaccessible) from 192.168.0.6 (192.168.0.6)
      Origin incomplete, metric 0, localpref 100, valid, internal
      Community: 2456:2456 no-export
  1, (Received from a RR-client)
    192.168.0.4 (metric 65) from 192.168.0.4 (192.168.0.4)
      Origin IGP, metric 0, localpref 100, valid, internal
  1, (Received from a RR-client)
    192.168.0.2 (metric 65) from 192.168.0.2 (192.168.0.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best

Since next-hop is no longer advertised, the trigger route is inaccessible. In turn, it will not be advertised to enforcing edge routers and will cause the attack traffic to be routed inside the infrastructure network. To fix this issue, we should add yet another static Null0 route, this time on R5.

R5:

ip route 192.0.2.1 255.255.255.255 Null0

Again, here we need to be careful that R5 does not advertise this route, or misconfigured edge router may send the traffic towards the router-reflector! Let’s see what we have learned from this.

Learned Lesson

Hopefully this small exercise with next-hop and filtering illustrated an important issue with RTBH. It is an extremely powerful feature, but it requires careful planning and implementation. More importantly, if it’s not implemented on all of the border routers, unintended targets such as route-reflectors or trigger router may become victims of a DDoS, instead of a server or an end user. This is a potential disaster.

Also, while inviting as an idea, setting next-hop on the trigger router may cause deeper issues and require more configuration throughout the network. It’s better avoided if not required.

I hope you enjoyed this article. Happy studies!

–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List

Print Friendly

First of all, let’s try to reproduce the problem. We will use the simple network shown on the diagram below for this purpose.

In the network we will use, R2 is a hub to which other routers connect to. R1 and R2 are connected in OSPF NSSA area 12 and R2 originates the default route to R1. See below.

R1:

router ospf 1
 area 12 nssa
 network 0.0.0.0 255.255.255.255 area 12
!

R1#show ip route | begin Gateway
Gateway of last resort is 12.12.12.2 to network 0.0.0.0

O*IA  0.0.0.0/0 [110/65] via 12.12.12.2, 00:35:15, Serial1/0
      1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback0
      12.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        12.12.12.0/24 is directly connected, Serial1/0
L        12.12.12.1/32 is directly connected, Serial1/0

R2:

router ospf 12
 area 12 nssa no-summary
 network 2.2.2.2 0.0.0.0 area 0
 network 12.12.12.2 0.0.0.0 area 12
!

R2#show ip route ospf | begin ^Gateway
Gateway of last resort is 0.0.0.0 to network 0.0.0.0

      1.0.0.0/32 is subnetted, 1 subnets
O        1.1.1.1 [110/65] via 12.12.12.1, 00:35:54, Serial1/0

R2 and R3 are using RIPv2. Again, R2 is the one originating the default route.

R3:

router rip
 version 2
 passive-interface default
 no passive-interface Serial1/1
 network 0.0.0.0
 no auto-summary
!

R3#show ip route | begin ^Gateway
Gateway of last resort is 23.23.23.2 to network 0.0.0.0

R*    0.0.0.0/0 [120/1] via 23.23.23.2, 00:00:26, Serial1/1
      3.0.0.0/32 is subnetted, 1 subnets
C        3.3.3.3 is directly connected, Loopback0
      23.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        23.23.23.0/24 is directly connected, Serial1/1
L        23.23.23.3/32 is directly connected, Serial1/1

R2:

router rip
 version 2
 passive-interface default
 no passive-interface Serial1/1
 network 23.0.0.0
 default-information originate
 no auto-summary
!

R2#show ip route rip | begin ^Gateway
Gateway of last resort is 0.0.0.0 to network 0.0.0.0

      3.0.0.0/32 is subnetted, 1 subnets
R        3.3.3.3 [120/1] via 23.23.23.3, 00:00:15, Serial1/1

Finally, R2 and R4 are using EIGRP. You guessed right – R2 originates the default to R4.

R4:

router eigrp 24
 network 0.0.0.0
 no auto-summary
!

R4#show ip route | begin ^Gateway
Gateway of last resort is 24.24.24.2 to network 0.0.0.0

D*    0.0.0.0/0 [90/2297856] via 24.24.24.2, 00:37:28, Serial1/2
      4.0.0.0/32 is subnetted, 1 subnets
C        4.4.4.4 is directly connected, Loopback0
      24.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        24.24.24.0/24 is directly connected, Serial1/2
L        24.24.24.4/32 is directly connected, Serial1/2

R2:

router eigrp 24
 network 24.24.24.2 0.0.0.0
 no auto-summary
!
interface Serial1/2
 ip summary-address eigrp 24 0.0.0.0 0.0.0.0
!

R2#show ip route eigrp | begin ^Gateway
Gateway of last resort is 0.0.0.0 to network 0.0.0.0

D*    0.0.0.0/0 is a summary, 00:38:27, Null0
      4.0.0.0/32 is subnetted, 1 subnets
D        4.4.4.4 [90/2297856] via 24.24.24.4, 00:39:18, Serial1/2

To sum this up, we can see that R2 has full visibility of all network, while other routers receive only default route from R2. We also have full reachability in the network. To preserve space, we’ll run the test only from R1, but it will work from all other routers as well.

R1:

R1#tclsh
R1(tcl)#foreach ip {
+>(tcl)#1.1.1.1
+>(tcl)#2.2.2.2
+>(tcl)#3.3.3.3
+>(tcl)#4.4.4.4
+>(tcl)#} { ping $ip source Loopback0 repeat 3 timeout 1 }

Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 1.1.1.1, timeout is 1 seconds:
Packet sent with a source address of 1.1.1.1
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 4/4/4 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2.2.2.2, timeout is 1 seconds:
Packet sent with a source address of 1.1.1.1
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 8/9/12 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 3.3.3.3, timeout is 1 seconds:
Packet sent with a source address of 1.1.1.1
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 16/18/20 ms
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 4.4.4.4, timeout is 1 seconds:
Packet sent with a source address of 1.1.1.1
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 16/17/20 ms
R1(tcl)#tclquit

BGP Configuration

To begin with, let’s configure BGP between R1 and R2 using Loopback0 as update-source. We will use iBGP.

R1:

router bgp 1234
 bgp router-id 1.1.1.1
 neighbor 2.2.2.2 remote-as 1234
 neighbor 2.2.2.2 update-source Loopback0
!

R2:

router bgp 1234
 bgp router-id 2.2.2.2
 neighbor 1.1.1.1 remote-as 1234
 neighbor 1.1.1.1 update-source Loopback0
!

If our premise is correct, nothing should happen, as BGP will not work from R1 to R2. However, after just couple of seconds, we should be seeing the following message on R1:

 %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up

How is this possible when the only route to 2.2.2.2 is the default route? Well, let’s examine this session a little bit. To do that, we’ll use “show ip bgp neighbor” command. We don’t need all the output for what I’m trying to illustrate, so I will filter it out a little bit using regular expressions and wonderful “| include” command modifier.

R1:

R1#show ip bgp neighbors 2.2.2.2 | include ^(Connection state|(Local|Foreign) host)
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 1.1.1.1, Local port: 179
Foreign host: 2.2.2.2, Foreign port: 13877

This looks normal, but there is one thing I’d like to especially point out. Look at the port numbers. Local port is 179 (BGP) and remote port is random high number. This means that it was R2 that initiated the session and R1 just accepted it. Let’s try to force the reverse.

R1:

router bgp 1234
 neighbor 2.2.2.2 transport connection-mode active
!

R2:

router bgp 1234
 neighbor 1.1.1.1 transport connection-mode passive
!

After clearing the sessions we don’t see the session being enabled. It’s time to call debug to assistance.

R1:

R1#debug ip bgp ipv4 unicast

Sure enough, after just few seconds, we’ll see the log message similar to the one below:

BGP: 2.2.2.2 Active open failed - no route to peer, open active delayed 13312ms (35000ms max, 60% jitter)

Conclusions

There are two important lessons we should learn here:

1. It is true that BGP will not actively open (initiate) BGP session with a peer if the only route to it is the default route.
2. If at least one of the peers has a more specific route to its peer and it actively opens the session, peer that has the default route to it will passively open (accept) the session.

This doesn’t really help us for the situation in which both peers have only default routes to each other. What do we do then?

Double Default

Let’s now focus on R3 and R4. They both have only default routes, but they can surely ping each other.

R3:

R3#ping 4.4.4.4 source Loopback0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/17/20 ms

Knowing what we learned in the last exercise, if we simply configure BGP between them, the session should not come up. Let’s put this knowledge to the test – with debug enabled.

R3:

router bgp 1234
 bgp router-id 3.3.3.3
 neighbor 4.4.4.4 remote-as 1234
 neighbor 4.4.4.4 update-source Loopback0
!

R4:

router bgp 1234
 bgp router-id 4.4.4.4
 neighbor 3.3.3.3 remote-as 1234
 neighbor 3.3.3.3 update-source Loopback0
!

After turning on the debug (using “debug ip bgp ipv4 unicast”), both routers will very soon let us know that they don’t have the routes to each other. At first glance, a hopeless situation.

In a sense, it is, but it’s not an unsolvable problem. Remember, routers are reachable, which mwans we could trick them into thinking they are directly connected using GRE tunnel. Of course, that means running a routing protocol over the tunnel or using static routes. Let’s take a look at that solution.

R3:

interface Tunnel34
 ip unnumbered Loopback0
 tunnel mode gre ip
 tunnel source Serial1/1
 tunnel destination 34.34.34.4
!
router ospf 1
 network 3.3.3.3 0.0.0.0 area 0
!

R4:

router ospf 1
 network 4.4.4.4 0.0.0.0 area 0
!
interface Tunnel34
 ip unnumbered Loopback0
 tunnel mode gre ip
 tunnel source Serial1/2
 tunnel destination 23.23.23.3
!

In just couple of seconds, our BGP neighbors will come up and our problem has been solved.

Happy studies!

Print Friendly

This is a solution in a search of a problem. Popular as it may be with CCIE workbook vendors and rumor has it with CCIE exam authors, real life has almost no use of this. When faced with a log message that you will read about in few paragraphs, solution is using the phone and not doing the other stuff I’m about to write. That said, it’s an interesting and fun problem.

Below is the network diagram that we’ll work with. It’s very simple and straightforward.

Both R1 and R2 were emulated using Dynamips and were running 12.2(31)SB13 IOS (Service Provider train). I’m sure that any other relatively newer IOS should work just fine.

Here are the relevant startup configurations for R1 and R2.

R1:

hostname R1
!
interface Loopback0
 ip address 192.168.0.1 255.255.255.255
!
interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
 speed 100
 duplex full
!
router bgp 65001
 no synchronization
 bgp log-neighbor-changes
 network 192.168.0.1 mask 255.255.255.255
 no auto-summary
!

R2:

hostname R2
!
interface Loopback0
 ip address 192.168.0.2 255.255.255.255
!
interface FastEthernet0/0
 ip address 192.168.12.2 255.255.255.0
 speed 100
 duplex full
!
router bgp 65002
 no synchronization
 bgp log-neighbor-changes
 network 192.168.0.2 mask 255.255.255.255
 no auto-summary
!

I would like to introduce several scenarios at this point.

• R1 needs to configure BGP with R2, but it doesn’t know R2′s AS number.
• R1 needs to configure BGP with R2, but R2 was configured to peer with another AS instead of 65001.

In all of the above scenarios, R2′s admin is unavailable, or unwilling to help and you, administrator of R1, are on your own. Naturally, as we don’t have R2′s admin to preconfigure R2, you are again on your own to paste the configs and immediately forget them. Hopefully, it won’t be too much to ask.

R1 needs to configure BGP with R2, but it doesn’t know R2′s AS number

Paste the following BGP configuration to R2 and forget its AS number.

router bgp 65002
 neighbor 192.168.12.1 remote-as 65001
!

With this configuration in place you should proceed to configure R1. However, you don’t know what AS number to use. You have one in 65535 chances of getting it right if you just use random one. Let’s pick 2.

R1(config)#router bgp 65001
R1(config-router)#nei 192.168.12.2 remote 2

Unless you guessed the AS number, after few seconds, R1 will display the following log message:

%BGP-3-NOTIFICATION: sent to neighbor 192.168.12.2 2/2 (peer in wrong AS) 2 bytes FDEA

… followed by some “nonsense” chain of hex numbers. While you could also decode those, they are not relevant for this case. Everything we need is right here in this log message.

Last 4 characters of the log message above, FDEA, are hex digits of the remote AS. If you convert them to decimal, they are 65002. Let’s reconfigure R1 to peer with 65002.

R1(config)#router bgp 65001
R1(config-router)#nei 192.168.12.2 remote 65002

Sure enough, after few seconds, we get the goody:

%BGP-5-ADJCHANGE: neighbor 192.168.12.2 Up

R1#ping 192.168.0.2 source lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/15/40 ms

Really, it’s that simple. This is the easier of the two. Before we continue to the next scenario, make sure to reload routers into startup configurations (or undo the changes).

R1 needs to configure BGP with R2, but R2 was configured to peer with another AS instead of 65001

Paste the following BGP configuration to R2 and forget the AS number.

router bgp 65002
 neighbor 192.168.12.1 remote-as 22
!

Proceed and configure R1 to peer with R2.

R1(config)#router bgp 65001
R1(config-router)#nei 192.168.12.2 remote 65002

Just like in the previous scenario, in a few seconds, you will receive the following message on R1:

%BGP-3-NOTIFICATION: received from neighbor 192.168.12.2 2/2 (peer in wrong AS) 2 bytes FDE9

You can jump and decode the last four characters, but only to be disappointed – that is our own AS number. Devil is in the detail and you can use it to your own advantage.

First of all, although very similar, message from scenario one and this one are not the same. Here they are, side by side:

%BGP-3-NOTIFICATION: sent to neighbor 192.168.12.2 2/2 (peer in wrong AS) 2 bytes FDEA
%BGP-3-NOTIFICATION: received from neighbor 192.168.12.2 2/2 (peer in wrong AS) 2 bytes FDE9

Note that in the first case, R1 was sending notification and in this case it’s receiving it. In a nutshell, this means that when BGP router receives OPEN message with remote AS indicating something else than what it has locally configured to be remote neighbor, it will send back notification to remote peer that it received something else than what it expected, also indicating what it received. However, what it will not send is any indication on what it wanted to see. Unfortunately, there is no technical solution for this problem. Even if you “sniff” the wire, you will not be able to see that R2 was configured to expect AS22.

I know that this is not exactly the answer you expected to get, but the whole excercise was not in vain. It’s not completely useless. By being able to read those two log messages above and fully understand what they are communicating, you can at least know which end is somehow misconfigured. If we take our second example further and assume that you received the answer from R2′s admin “I configured remote-as as 22 and I can’t change it, because I’m in Fiji”, how do you solve the peering problem? Of course, you can change the AS of your local BGP router, but that may not be doable if you have more than just a few. Hopefully, Cisco has an ace up its sleeve for that.

R1(config)#router bgp 65001
R1(config-router)#nei 192.168.12.2 local-as 22 no-prepend replace-as

When configured like so, R2 will be completely unaware that R1 is actually AS65001:

R2#sh ip bgp 192.168.0.1
BGP routing table entry for 192.168.0.1/32, version 5
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x420
 Not advertised to any peer
 22
   192.168.12.1 from 192.168.12.1 (192.168.0.1)
     Origin IGP, metric 0, localpref 100, valid, external, best

Also, R1 and its other BGP peers will not see AS22 in any updates:

R1#sh ip bgp 192.168.0.2
BGP routing table entry for 192.168.0.2/32, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x420
 Not advertised to any peer
 65002
   192.168.12.2 from 192.168.12.2 (192.168.0.2)
     Origin IGP, metric 0, localpref 100, valid, external, best

Mandatory reachability test:

R1#ping 192.168.0.2 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/13/40 ms

I hope that this tutorial was of some use. If that’s the case, please leave some feedback.

This article was originally posted on my personal blog on October 8, 2009. It is reproduced here with permission.

–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List

Print Friendly

BGP Outbound Route Filtering

R1 and R2 are EBGP Neighbors. R1 is receiving the following routes from R2:

R1#sho ip bgp | be Net
Network          Next Hop            Metric LocPrf Weight Path
*> 200.0.0.0        192.168.12.2             0             0 200 i
*> 200.0.1.0        192.168.12.2             0             0 200 i
*> 200.0.2.0        192.168.12.2             0             0 200 i
*> 200.0.3.0        192.168.12.2             0             0 200 i
R1#

Suppose R1 wants to only allow the first 2 routes. We could do it with a prefix-list as follows:

R1(config)#ip prefix-list FROMR2 permit 200.0.0.0/24
R1(config)#ip prefix-list FROMR2 permit 200.0.1.0/24
R1(config)#router bgp 100
R1(config-router)#neighbor 192.168.12.2 prefix-list FROMR2 in

When debugging, we can see that the last two prefixes get denied at R1:

R1#debug ip bgp updates in
BGP updates debugging is on (inbound) for address family: IPv4 Unicast
R1#cle ip bgp *
R1#
*Mar  1 00:06:21.491: %BGP-5-ADJCHANGE: neighbor 192.168.12.2 Down User reset
*Mar  1 00:06:22.627: %BGP-5-ADJCHANGE: neighbor 192.168.12.2 Up
*Mar  1 00:06:22.683: BGP(0): 192.168.12.2 rcvd UPDATE w/ attr: nexthop 192.168.12.2, origin i, metric 0, path 200
*Mar  1 00:06:22.687: BGP(0): 192.168.12.2 rcvd 200.0.3.0/24 -- DENIED due to: distribute/prefix-list;
*Mar  1 00:06:22.695: BGP(0): 192.168.12.2 rcvd 200.0.2.0/24 -- DENIED due to: distribute/prefix-list;
*Mar  1 00:06:22.699: BGP(0): 192.168.12.2 rcvd 200.0.1.0/24
*Mar  1 00:06:22.699: BGP(0): 192.168.12.2 rcvd 200.0.0.0/24

Wouldn’t it be nice if R1 could somehow tell R2 not to send those prefixes anyway, since R1 will just deny them? Well that’s what outbound route filterin(ORF) does. Configuration is simple. Since R1 is the one sending the prefix-list to R2, it will have the send keyword:

R1(config)#router bgp 100
R1(config-router)#neighbor 192.168.12.2 capability orf prefix-list send
R2(config)#router bgp 200
R2(config-router)#neighbor 192.168.12.1 capability orf prefix-list receive

Let’s clear ip bgp again:

R1#cle ip bgp *
R1#
*Mar  1 00:12:21.755: %BGP-5-ADJCHANGE: neighbor 192.168.12.2 Down User reset
*Mar  1 00:12:23.571: %BGP-5-ADJCHANGE: neighbor 192.168.12.2 Up
*Mar  1 00:12:23.627: BGP(0): 192.168.12.2 rcvd UPDATE w/ attr: nexthop 192.168.12.2, origin i, metric 0, path 200
*Mar  1 00:12:23.631: BGP(0): 192.168.12.2 rcvd 200.0.1.0/24
*Mar  1 00:12:23.635: BGP(0): 192.168.12.2 rcvd 200.0.0.0/24
*Mar  1 00:12:23.723: BGP(0): Revise route installing 1 of 1 routes for 200.0.0.0/24 -> 192.168.12.2(main) to main IP table
*Mar  1 00:12:23.727: BGP(0): Revise route installing 1 of 1 routes for 200.0.1.0/24 -> 192.168.12.2(main) to main IP table

We don’t see any message about R1 denying pre fixes because R2 is now doing the filtering.  How can we verify on R2? With the sho ip bgp neighbors command. For brevity, this is only a partial output:

R2#sho ip bgp neighbors
AF-dependant capabilities:
Outbound Route Filter (ORF) type (128) Prefix-list:
Send-mode: received
Receive-mode: advertised
Outbound Route Filter (ORF): received (2 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:                        2        n/a
Total:                                  2          0

From the above output we can also see that R2 is advertising itself in receive mode (accepts the ORF) while the neighbor is in send-mode (sends the ORF to R2). Also the ORF permits 2 entries which is the value next to “Prefixes Current” and “Prefixes Total.” In the bottom section we see that R2 has 2 locally denied prefixes due to “ORF prefix-list.”

Regards, Bryan (Post by Bryan Bartik)

Print Friendly

R2 (AS #2) and R3 (AS #3) are BGP Peers. R3 and R4 are OSPF neighbors. R2 is advertising 192.168.12.0 and R3 is redistributing it into OSPF.

After initial configuration R4 has the following entry. Notice the tag is equal to the AS number that originated the route:

R4#sho ip route 192.168.12.0
Routing entry for 192.168.12.0/24
Known via "ospf 1", distance 110, metric 1
Tag 2, type extern 2, forward metric 64
Last update from 192.168.34.3 on Serial1/0, 00:00:36 ago
Routing Descriptor Blocks:
* 192.168.34.3, from 3.3.3.3, 00:00:36 ago, via Serial1/0
Route metric is 1, traffic share count is 1
Route tag 2

We can alter this tag a couple ways. We can use a route-map during redistribution or use a table-map. The table-map is easy to configure:

R3(config)#route-map TABLE
R3(config-route-map)#set tag 500
R3(config-route-map)#exit
R3(config)#router bgp 3
R3(config-router)#table-map TABLE
R3(config-router)#exit
R3(config)#exit
R3#clear ip rou *

Make sure to clear the route table to see the changes. Since this command takes effect between the BGP table and Route table, we don’t need to clear BGP. Now let’s look on R4:

R4#sho ip route 192.168.12.0
Routing entry for 192.168.12.0/24
Known via "ospf 1", distance 110, metric 1
Tag 500, type extern 2, forward metric 64
Last update from 192.168.34.3 on Serial1/0, 00:01:09 ago
Routing Descriptor Blocks:
* 192.168.34.3, from 3.3.3.3, 00:01:09 ago, via Serial1/0
Route metric is 1, traffic share count is 1
Route tag 500

The tag is now set to 500. It’s always good know more than one way to do things. :)

Regards, Bryan (Blog Post by Bryan Bartik)

Print Friendly

Generally speaking, for EBGP peering using the BGP standards, we peer based on the IP address of the BGP neighbors’ local interfaces. However, that brings up some challenging permutations. When peering is done via the external network of a BGP edge router within an AS, a BGP edge router will not change the next hop of for the route from the advertising AS when it receives it but rather will pass it on unchanged to its IBGP neighbors.

If the external network connecting the two AS’s is not advertised into the IGP of the receiving AS, the next hop of the route will presumably be unreachable.

So this presents us with a few options…

1. We can redistribute the external network into the IGP.
2. We can advertise the external network into the IGP (presumably as a passive interface).
3. We can configure the next hop self parameter on the edge router on the receiving AS’s internal neighbor relationships.

Being aware of all three methods is important to understanding the options available to you should you need to configure “RFC-compliant” BGP. My personal preference is setting the next-hop-self parameter on each of the edge router’s IBGP connections, thus ensuring a reachable next hop without increasing the size of the IGP table. It is not necessarily going to maintain the most optimal routing path to exit the AS (due to the default BGP path selection process being inferior to that of an IGP) but it consistently works to establish connectivity.

What is your preference? I welcome your comments!

Print Friendly

Looking at these numbers, I find that quite an oddity. Obviously, R&S is by far the most popular track and, like most people, it was the first that I undertook. By far the greatest intellectual achievement of my lifetime was obtaining my first CCIE. However, having done so like many people with the study bug, it is worth considering what to study next.

I observe two different paths to a SP CCIE. The first is for those who choose to take it as their first track (a bit over half of SP candidates). This category is presumably comprised of students who work with SP technologies on a daily basis – BGP, MPLS and MPLS VPNs. For this class of student, it seems like the most obvious choice to take as the technologies of the SP track are fairly well focused on building and establishing SP networks with intense protocol dependencies. For those who take this path, the rationale is clear.

The second path, the path that I took and that I’d like to advocate to many others is for R&S CCIEs to expand their level of knowledge and, in my opinion, complete what you started by fully demonstrating your expertise with Cisco routers in any environment.

The R&S track requires you to learn many IGP routing protocols, but in recent times it leaves you with missing a few key technologies required to move from the enterprise to the service provider space. How many job advertisements request an R&S CCIE but also specify MPLS and BGP expertise as well? From my own observations, quite a few.

Having learned to study and achieve your R&S goals, the incremental level of study and knowledge required to obtain the SP CCIE is relatively small. The additional technologies can be learned relatively easily by virtue of analogy and be slotting them into the mental framework you have already established in learning R&S.

Learning ATM is simple by analogy with Frame Relay. Learning IS-IS is straightforward by contrast with OSPF and the ideas of IPv6 (with respect to multiple protocols running over a network as CLNS does). BGP, which is covered well in the R&S track, needs only to be expanded on for other protocols to meet the SP requirements and, after having done so, certain vagaries that were enough to achieve R&S status become clearer.

Which leaves MPLS, VPNs and MPLS Traffic Engineering. These technologies, some of the cleverest innovations in the recent history of networking are the technologies of the future both in service provider networks and large enterprises. Put simply, MPLS takes a whole set of discontiguous routes (or other FECs) and labels them, thus reducing the overhead on routers of routing table lookups and switches the labels throughout the network. Traffic Engineering gives you the ability integrate QOS requirements into the MPLS process to fully control your network.

To me, understanding routers and switches was the goal of my study for R&S. Having completed the R&S CCIE, it irked me that whilst in a sense I had finished, the more I knew, the more I knew I didn’t know! Service Provider provided, in many ways, a feeling of completion to my studies.

For those of you who have or are about to complete your R&S track, I urge you to consider SP as your second. Voice is another beast entirely (one that I’m still in the process of attaining) and Security builds on R&S in a different manner by applying the protocols on a different set of platforms (amongst other things).

SP is unique in that, with R&S in hand, you already know half of what you need to succeed and on learning the final half you gain a better perspective around both your enterprise and service provider technological understanding. If you are looking to distinguish yourself from others, this is the best return on investment in terms of time required to study to achieve a second CCIE of any of the options available.

In my opinion, when you achieve it, that takes you from one of 16000 R&S CCIEs without recognition of that knowledge, to one of the 440 with it. Surely, that must be worth something, be it intellectual satisfaction or remunerative opportunities.

What are your thoughts?

Print Friendly