CCIE Training

I enjoyed Petr’s article regarding explicit next hop.  It reminded me of a scenario where a redistributed route, going into OSPF conditionally worked, depending on which reachable next hop was used.

Here is the topology for the scenario:

Here is the relevant (and working ) information for R1.

When we replace the static route, with a new reachable next hop, we loose the ability to ping 100.100.100.3

When we change the next hop for the static route, (which is being redistributed into OSPF), the route to 100.100.100.0/24 no longer works, even though we have verified ability to ping the new next hop.

Can you solve this puzzle?  Please post your ideas!

For more troubleshooting scenarios, please see our CCIE Route-Switch workbooks, volume 2, for more than 100 challenging troubleshooting scenarios.

We will post the results right here, in a few days, after you have had a chance to post your comments and ideas.

Best wishes,

Keith

Last week we wrapped up the MPLS bootcamp, and it was a blast!   A big shout out to all the students who attended,  as well as to many of the INE staff who stopped by (you know who you are ).    Thank you all.

Here is the topology we used for the class, as we built the network, step by step.

The class was organized and delivered in 30 specific lessons. Here is the “overview” slide from class:

One of the important items we discussed was troubleshooting.   When we understand all the components of Layer3 VPNs, the troubleshooting is easy.   Here are the steps:

• Can PE see CE’s routes?
• Are VPN routes going into MP-BGP?  (The Export)
• Are remote PEs seeing the VPN routes?
• Are remote PEs inserting the VPN routes into the correct local VRF? (The Import)
• Are remote PEs, advertising these to remote CEs?
• Are the remote CEs seeing the routes?

We had lots of fun, and included wireshark protocol analysis, so we could see and verify what we were learning.   Here is one example, of a BGP updated from a downstream iBGP neighbor which includes the VPN label:

If you missed the class, but still want to benefit from it, we have recorded all 30 sessions, and it is available as an on-demand version of the class.

Next week, the BGP bootcamp is running, so if you need to  brush up on BGP, we will be covering the following topics, also  in 30, easy to digest lessons:

• Monitoring and Troubleshooting BGP
• Multi-Homed BGP Networks
• AS-Path Filters
• Prefix-List Filters
• Outbound Route Filtering
• Route-Maps as BGP Filters
• BGP Path Attributes
• BGP Local Preference
• BGP Multi-Exit-Discriminator (MED)
• BGP Communities
• BGP Customer Multi-Homed to a Single Service Provider
• BGP Customer Multi-Homed to Multiple Service Providers
• Transit Autonomous System Functions
• Packet Forwarding in Transit Autonomous Systems
• Monitoring and Troubleshooting IBGP in Transit AS
• Network Design with Route Reflectors
• Limiting the Number of Prefixes Received from a BGP Neighbor
• AS-Path Prepending
• BGP Peer Group
• BGP Route Flap Dampening
• Troubleshooting Routing Issues
• Scaling BGP

I look forward to seeing you in class!

Best wishes in all of your learning,

Keith Barker

Time is a valuable resource in the lab.   In a lab task, if asked to configure a policy-map named “BOB”, it doesn’t get the same point value if we happen to accidentally name it “bob”, especially  if they are looking to see if you configured what they asked for.

The challenge is, that when reviewing a lab task, and we discover that we need to change a name, it could be a hassle, as we need to remove the policy-map, recreate the policy map, and then put it in place again.

So if you are down to the last minute, here is a time saving solution, that can assist with that process.

IOS allows us to rename a policy-map, and the IOS will swap out the name in other areas of the configuration that reference that policy map.

Here is an example, of a policy map from Volume 2, lab 5.

Rack1R5#show run policy-map
Building configuration...

Current configuration : 352 bytes
!
policy-map TRANSIT_RATE_LIMIT
class FRAGMENTS
   police rate 1000000 pps burst 200000 packets
policy-map type port-filter HOST_PORT_FILTER
class CLOSED_PORTS
   drop
policy-map CEF_EXCEPTION_RATE_LIMIT
class class-default
   police rate 100 pps burst 20 packets
policy-map HOST_RATE_LIMIT
class ICMP
   police rate 10 pps burst 5 packets
!
end

Rack1R5#show run | begin control
control-plane host
service-policy input HOST_RATE_LIMIT
service-policy type port-filter input HOST_PORT_FILTER
!
control-plane transit
service-policy input TRANSIT_RATE_LIMIT
!
control-plane cef-exception
service-policy input CEF_EXCEPTION_RATE_LIMIT

Let’s say that after reviewing our configuration, we discovered that the policy-map for the cef-exception sub interface of the control plane should have been named “NEW-NAME-CEF”.

To change it everywhere in the configuration, instead of creating it new, and replacing it, we could simply do this:

Rack1R5(config)#policy-map CEF_EXCEPTION_RATE_LIMIT
Rack1R5(config-pmap)#rename NEW-NAME-CEF

Now, when we look at the configuration, we can see that not only the name has changed for the policy-map, but it also updated our control-plane configuration to reflect the new name there as well:

Rack1R5#show run policy-map
Building configuration...

Current configuration : 340 bytes
!
policy-map TRANSIT_RATE_LIMIT
class FRAGMENTS
   police rate 1000000 pps burst 200000 packets
policy-map type port-filter HOST_PORT_FILTER
class CLOSED_PORTS
   drop
policy-map NEW-NAME-CEF
class class-default
   police rate 100 pps burst 20 packets
policy-map HOST_RATE_LIMIT
class ICMP
   police rate 10 pps burst 5 packets
!
end

Rack1R5#show run | begin control
control-plane host
service-policy input HOST_RATE_LIMIT
service-policy type port-filter input HOST_PORT_FILTER
!
control-plane transit
service-policy input TRANSIT_RATE_LIMIT
!
control-plane cef-exception
service-policy input NEW-NAME-CEF
!
!

Best wishes on your studies, and may your policy-maps be named correctly the first time around.

Keith

Can you solve this puzzle?

R2, R3 and R4 create the service provider network, with MPLS on all three routers, and iBGP at the PE routers.  R1 and R5 are the CE routers.

R2, prefers the BGP next hop of 4.4.4.4 for network 5.5.5.5 (R5 loopback). R4, at 4.4.4.4 is an iBGP neighbor.

R2#show ip route vrf v | inc 5.5.5.0
B       5.5.5.0 [200/409600] via 4.4.4.4, 00:06:47

Is R2 preferring an iBGP learned route, which has an AD of 200, over a EIGRP route, which would have an AD of 90?

Can you identify why the routing for 5.5.5.0 on the VRF of R2 is using BGP instead of EIGRP?

Below are the relevant portions of the configuration, which also can serve as a great review of how to configure MPLS VPNs.
R1, CE router:

R1#show run
interface Loopback0
 ip address 1.1.1.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 10.1.12.1 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0
 ip address 10.1.215.1 255.255.255.0
!

router eigrp 1
 network 0.0.0.0
 no auto-summary

R2, PE Router:

R2#show run
!
ip vrf v
 rd 1:1
 route-target export 1:1
 route-target import 1:1
!
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip vrf forwarding v
 ip address 10.1.12.2 255.255.255.0
!
interface FastEthernet0/1
 ip address 10.1.23.2 255.255.255.0
 ip ospf 1 area 0
 mpls ip
!
router eigrp 1
 no auto-summary
 !
 address-family ipv4 vrf v
  redistribute bgp 234 metric 1 10000 1 1 1
  network 10.1.12.2 0.0.0.0
  auto-summary
  autonomous-system 1
 exit-address-family
!
router ospf 1
 log-adjacency-changes
!
router bgp 234
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 4.4.4.4 remote-as 234
 neighbor 4.4.4.4 update-source Loopback0
 !
 address-family vpnv4
  neighbor 4.4.4.4 activate
  neighbor 4.4.4.4 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf v
  redistribute eigrp 1
  no synchronization
 exit-address-family
!
ip forward-protocol nd
!

R3, P router:

R3#show run

interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.1.34.3 255.255.255.0
 mpls ip
!
interface FastEthernet0/1
 ip address 10.1.23.3 255.255.255.0
 mpls ip
!
router ospf 1
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0
!

R4: PE Router

R4#show run
!
ip vrf v
 rd 1:1
 route-target export 1:1
 route-target import 1:1
!
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 10.1.34.4 255.255.255.0
 ip ospf 1 area 0
 mpls ip
!
interface FastEthernet0/1
 ip vrf forwarding v
 ip address 10.1.45.4 255.255.255.0
!
router eigrp 1
 no auto-summary
 !
 address-family ipv4 vrf v
  redistribute bgp 234 metric 1 1 1 1 1
  network 10.1.45.4 0.0.0.0
  auto-summary
  autonomous-system 1
 exit-address-family
!
router ospf 1
 log-adjacency-changes
!
router bgp 234
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 234
 neighbor 2.2.2.2 update-source Loopback0
 !
 address-family vpnv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf v
  redistribute eigrp 1
  no synchronization
 exit-address-family

R5: CE Router

R5#show run
!
interface Loopback0
 ip address 5.5.5.5 255.255.255.0
!
interface Serial0/0
 ip address 10.1.215.5 255.255.255.0
 clock rate 64000
!
interface FastEthernet0/1
 ip address 10.1.45.5 255.255.255.0
!
router eigrp 1
 network 0.0.0.0
 no auto-summary
!

Now for a couple show commands on R1:

R1#show ip route eigrp
     5.0.0.0/24 is subnetted, 1 subnets
D       5.5.5.0 [90/435200] via 10.1.12.2, 00:19:08, FastEthernet0/0
     10.0.0.0/24 is subnetted, 3 subnets
D       10.1.45.0 [90/307200] via 10.1.12.2, 00:19:08, FastEthernet0/0
R1#

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(10.1.215.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 1.1.1.0/24, 1 successors, FD is 128256
        via Connected, Loopback0
P 5.5.5.0/24, 1 successors, FD is 435200
        via 10.1.12.2 (435200/409600), FastEthernet0/0
        via 10.1.215.5 (2297856/128256), Serial0/0
P 10.1.12.0/24, 1 successors, FD is 281600
        via Connected, FastEthernet0/0
P 10.1.45.0/24, 1 successors, FD is 307200
        via 10.1.12.2 (307200/281600), FastEthernet0/0
        via 10.1.215.5 (2195456/281600), Serial0/0
P 10.1.215.0/24, 1 successors, FD is 2169856
        via Connected, Serial0/0
R1#

And some on R2, the PE router:

R2#show ip route vrf v

Routing Table: v
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     1.0.0.0/24 is subnetted, 1 subnets
D       1.1.1.0 [90/409600] via 10.1.12.1, 00:31:48, FastEthernet0/0
     5.0.0.0/24 is subnetted, 1 subnets
B       5.5.5.0 [200/409600] via 4.4.4.4, 00:02:34
     10.0.0.0/24 is subnetted, 3 subnets
C       10.1.12.0 is directly connected, FastEthernet0/0
B       10.1.45.0 [200/0] via 4.4.4.4, 00:31:48
D       10.1.215.0 [90/2195456] via 10.1.12.1, 00:31:21, FastEthernet0/0

R2#show ip eigrp vrf v topology
IP-EIGRP Topology Table for AS(1)/ID(10.1.12.2) Routing Table: v

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 1.1.1.0/24, 1 successors, FD is 409600
        via 10.1.12.1 (409600/128256), FastEthernet0/0
P 5.5.5.0/24, 1 successors, FD is 409600
        via VPNv4 Sourced (409600/0)
P 10.1.12.0/24, 1 successors, FD is 281600
        via Connected, FastEthernet0/0
P 10.1.45.0/24, 1 successors, FD is 281600
        via VPNv4 Sourced (281600/0)
P 10.1.215.0/24, 1 successors, FD is 2195456
        via 10.1.12.1 (2195456/2169856), FastEthernet0/0
R2#

Take a minute to post your thoughts, and as always, happy studies.

Keith

It has been a few days, and we have received lots of great ideas.   Thank you.

When R4 receives the routes in VRF v, the EIGRP metrics are copied into extended BGP attributes, and include the information for metric, AS, route-type and more.  The iBGP updates from R4 to R2 contain all those attributes.   When R2 receives the updates, if the route type is internal (from EIGRP attributes) and the source EIGRP AS matches the local EIGRP AS we are importing to, it will then be up to the  metric to determine the best path.

If we decreased the bandwidth statement on R4 Fa0/1, or used an offset list (2,000,000 more should do the trick) on R5 out Fa0/1 (towards R4), the increase in metric would cause R2 to prefer the path through R1 for 5.5.5.0/24 instead of using the MPLS backbone.

BGP updates that contain the cost community attribute will use the EIGRP AD instead of the iBGP AD of 200 to compare routes on metric alone. In that light, another option, would be to tell R2 to ignore cost-community, with the BGP router command:

bgp bestpath cost-community ignore

Let’s take a look at the results.

Here is the baseline for before any changes:

R2#show ip route vrf v | inc 5.5.5
B       5.5.5.0 [200/409600] via 4.4.4.4, 00:02:29
R2#show ip bgp vpnv4 all 5.5.5.0
BGP routing table entry for 1:1:5.5.5.0/24, version 8
Paths: (1 available, best #1, table v)
Flag: 0x820
  Not advertised to any peer
  Local
    4.4.4.4 (metric 21) from 4.4.4.4 (4.4.4.4)
      Origin incomplete, metric 409600, localpref 100, valid, internal, best
      Extended Community: RT:1:1 Cost:pre-bestpath:128:409600 0x8800:32768:0
        0x8801:1:153600 0x8802:65281:256000 0x8803:65281:1500
      mpls labels in/out nolabel/19
R2#

Now we will remove the default behavior

R2(config)#router bgp 234
R2(config-router)#bgp bestpath cost-community ignore

Cleared BGP sessions and routing tables, and waited a minute before the following show commands:

R2#show ip route vrf v | inc 5.5.5
D       5.5.5.0 [90/2323456] via 10.1.12.1, 00:00:08, FastEthernet0/0
R2#show ip bgp vpnv4 all 5.5.5.0
BGP routing table entry for 1:1:5.5.5.0/24, version 8
Paths: (2 available, best #2, table v)
Flag: 0x820
  Advertised to update-groups:
        1
  Local
    4.4.4.4 (metric 21) from 4.4.4.4 (4.4.4.4)
      Origin incomplete, metric 409600, localpref 100, valid, internal
      Extended Community: RT:1:1 Cost:pre-bestpath:128:409600 0x8800:32768:0
        0x8801:1:153600 0x8802:65281:256000 0x8803:65281:1500
      mpls labels in/out 20/19
  Local
    10.1.12.1 from 0.0.0.0 (2.2.2.2)
      Origin incomplete, metric 2323456, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:1:1
        Cost:pre-bestpath:128:2323456 (default-2145160191) 0x8800:32768:0
        0x8801:1:665600 0x8802:65282:1657856 0x8803:65281:1500
      mpls labels in/out 20/nolabel
R2#

After setting it back to defaults, we could then try an offset list on R5 advertising to R4:

R5(config)#router eigrp 1
R5(config-router)#offset-list 0 out 2000000 fastEthernet 0/1

Cleared BGP sessions and routing tables, and waited a minute before the following show commands:

R2#show ip route vrf v | inc 5.5.5
D       5.5.5.0 [90/2323456] via 10.1.12.1, 00:06:28, FastEthernet0/0
R2#show ip bgp vpnv4 all 5.5.5.0
BGP routing table entry for 1:1:5.5.5.0/24, version 12
Paths: (1 available, best #1, table v)
Flag: 0x820
  Advertised to update-groups:
        1
  Local
    10.1.12.1 from 0.0.0.0 (2.2.2.2)
      Origin incomplete, metric 2323456, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:1:1
        Cost:pre-bestpath:128:2323456 (default-2145160191) 0x8800:32768:0
        0x8801:1:665600 0x8802:65282:1657856 0x8803:65281:1500
      mpls labels in/out 31/nolabel
R2#

After resetting all that, implementing the following on R4, and then clearing BGP and routing, we issue the show commands again.

R4(config)#int fa 0/1
R4(config-if)#bandwidth 100

R2#show ip route vrf v | inc 5.5.5
D       5.5.5.0 [90/2323456] via 10.1.12.1, 00:00:05, FastEthernet0/0
R2#show ip bgp vpnv4 all 5.5.5.0
BGP routing table entry for 1:1:5.5.5.0/24, version 20
Paths: (1 available, best #1, table v)
Flag: 0x820
  Advertised to update-groups:
        1
  Local
    10.1.12.1 from 0.0.0.0 (2.2.2.2)
      Origin incomplete, metric 2323456, localpref 100, weight 32768, valid, sourced, best
      Extended Community: RT:1:1
        Cost:pre-bestpath:128:2323456 (default-2145160191) 0x8800:32768:0
        0x8801:1:665600 0x8802:65282:1657856 0x8803:65281:1500
      mpls labels in/out 23/nolabel
R2#

Thanks again to all who contributed. I encourage all RS candidates to lab this up, as well as practice MPLS with OSPF at the CEs.

Marcel posted a comment, reminding us of an excellent document written by Petr, on this topic and more. The original post from Petr which includes the link to free .PDF for this document may be found by clicking here. Thanks Marcel!

Are you ready to explore the following?

• HSRP
• VRRP
• GLBP
• NTP
• DHCP
• DNS
• WCCP

Check out the latest chapter posted in the Advanced Technologies Class On Demand.

Next week watch for the final chapter on Network Optimization, where we explore such critical Version 4 topics like EEM, IP SLA, and much more.

Also, soon here on the blog site, watch for a Video Blog episode that discusses study and lab exam strategy for the massive body of knowledge that is IP Services/Optimization in general.

The new version of the best-selling video series, Advanced Technologies Class on Demand (ATCoD) from INE has been updated with Chapters 8 and 9. These topics are Security and QoS respectively.

The final two chapters of the new course, Network Services and Network Optimization, are currently in production and will be posted no later than July 31, 2010.

Enjoy the new lessons everyone!

“Why doesn’t this PING work!?!”

Here is a simple 3 router configuration, well at least it is simple on 2 of the 3 routers. R1 and R3 are configured quite traditionally, but R2 is a bit more involved.
Here is the diagram.

Here are the details.

R2 is using a VRF which includes both LAN interfaces. R2 is also acting as a Zone Based Firewall in transparent mode, allowing all ICMP traffic in both directions, as well as SSH from the inside to the outside networks. R2 has a bridged virtual interface in the 10.123.0.0/24 network. All are running OSPF, but pings issued from R2 to the loopbacks of R1 and R3 are failing.

Can you identify why?
Here is the relevant output:

R1#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           1   FULL/DR         00:00:39    10.123.0.3      FastEthernet0/0
10.123.0.2        1   FULL/BDR        00:00:32    10.123.0.2      FastEthernet0/0
R1#show ip route ospf
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/2] via 10.123.0.3, 00:01:33, FastEthernet0/0

R1#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/88/172 ms
R1#ssh -l admin 3.3.3.3
Password: <password>

R3#show ssh
Connection Version Mode Encryption  Hmac         State                 Username
0          1.99     IN   aes128-cbc  hmac-sha1    Session started       admin
0          1.99     OUT  aes128-cbc  hmac-sha1    Session started       admin
%No SSHv1 server connections running.
R3#exit

[Connection to 3.3.3.3 closed by foreign host]
R1#

Now for R2:

R2#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/DROTHER    00:00:37    10.123.0.1      BVI1
3.3.3.3           1   FULL/DR         00:00:35    10.123.0.3      BVI1

R2#show ip route ospf

R2#show policy-map type inspect zone-pair
 Zone-pair: zp-in-to-out

  Service-policy inspect : p-in-to-out

    Class-map: c-in-to-out (match-any)
      Match: protocol icmp
        4 packets, 320 bytes
        30 second rate 0 bps
      Match: protocol ssh
        3 packets, 72 bytes
        30 second rate 0 bps
      Inspect
        Packet inspection statistics [process switch:fast switch]
        tcp packets: [4:390]
        icmp packets: [0:50]

        Session creations since subsystem startup or last reset 8
        Current session counts (estab/half-open/terminating) [0:0:0]
        Maxever session counts (estab/half-open/terminating) [2:1:1]
        Last session created 00:02:23
        Last statistic reset never
        Last session creation rate 0
        Maxever session creation rate 3
        Last half-open session total 0

    Class-map: class-default (match-any)
      Match: any
      Drop (default action)
        0 packets, 0 bytes
 Zone-pair: zp-out-to-in

  Service-policy inspect : p-out-to-in

    Class-map: c-out-to-in (match-all)
      Match: protocol icmp
      Inspect
        Packet inspection statistics [process switch:fast switch]
        icmp packets: [0:20]

        Session creations since subsystem startup or last reset 2
        Current session counts (estab/half-open/terminating) [0:0:0]
        Maxever session counts (estab/half-open/terminating) [1:1:0]
        Last session created 00:25:24
        Last statistic reset never
        Last session creation rate 0
        Maxever session creation rate 1
        Last half-open session total 0

    Class-map: class-default (match-any)
      Match: any
      Drop (default action)
        4 packets, 96 bytes

R2#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R2# show run
version 12.4
hostname R2
!
ip vrf myvrf
!
class-map type inspect match-any c-in-to-out
 match protocol icmp
 match protocol ssh
class-map type inspect match-all c-out-to-in
 match protocol icmp
!
policy-map type inspect p-in-to-out
 class type inspect c-in-to-out
  inspect
 class class-default
policy-map type inspect p-out-to-in
 class type inspect c-out-to-in
  inspect
 class class-default
!
zone security inside
zone security outside
zone-pair security zp-in-to-out source inside destination outside
 service-policy type inspect p-in-to-out
zone-pair security zp-out-to-in source outside destination inside
 service-policy type inspect p-out-to-in
bridge irb
!
interface FastEthernet0/0
 ip vrf forwarding myvrf
 no ip address
 zone-member security inside
 bridge-group 1
!
interface FastEthernet0/1
 ip vrf forwarding myvrf
 no ip address
 zone-member security outside
 bridge-group 1
!
interface BVI1
 ip vrf forwarding myvrf
 ip address 10.123.0.2 255.255.255.0
!
router ospf 1 vrf myvrf
 router-id 10.123.0.2
 network 0.0.0.0 255.255.255.255 area 0
!
bridge 1 protocol ieee
bridge 1 route ip
end

Here is R3:

R3#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/DROTHER    00:00:32    10.123.0.1      FastEthernet0/1
10.123.0.2        1   FULL/BDR        00:00:31    10.123.0.2      FastEthernet0/1

R3#show ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/2] via 10.123.0.1, 00:29:36, FastEthernet0/1

R3#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 76/117/176 ms
R3#

Similar configuration scenarios are included in both our RS and SC workbooks at INE.

Take a moment, and post your ideas on why the PING from R2 is failing, and thanks for taking the time to assist!

Best wishes, Keith

Summer was in full swing, and it was over 105 degrees Fahrenheit outside.   Bob was told it was a “dry heat”, but he thought “so is my oven”.  Needless to say, Bob was glad to be in the data center, where the temperature and humidity controls kept it very cold.   He had been asked to setup up a basic route-map with BGP, and here is the diagram he worked from.

The goal, was to modify BGP,  so that all traffic going towards the 1.1.1.0 network (which is sourced from AS1), traveling either from or through AS23, would only use the 13.0.0.0/24 segment (between R3 and R1), and not use the 10.0.0.0/24 segment (between R2 and R1) as a transit path.
Bob reviewed some of the BGP topics he had recently learned.   Here is the list he made of possibilities:
R1 could pre-pend to the AS path for advertisements of the 1.1.1.0/24 prefix when it is sent to R2 from R1.   This way, AS23 would see a better path through R3 rather than R2.  He tried this using the following on R1:

ip prefix-list JUST-1.1.1.0 seq 5 permit 1.1.1.0/24

route-map PRE-PEND permit 10
 match ip address prefix-list JUST-1.1.1.0
 set as-path prepend 1
route-map PRE-PEND permit 20

router bgp 1
 neighbor 10.0.0.2 route-map PRE-PEND out

Bob cleared the BGP session, just to be sure.    Unfortunately, some traffic destined to 1.1.1.0 was still flowing over the 10.0.0.0 network between R2 and R1.

Bob decided to try another approach, and instead of R1 trying to make AS23 think the path on 10.0.0.0 was worse, perhaps he would tell R3 to make the path on 13.0.0.0 look better.    He considered weight, but then realized that would only work for R3, and not every other device in AS23.    So Bob decided to use local-preference.  On R3, he tried using local-preference, to specify that when a BGP update came in from R1 for 1.1.1.0, R3 would set the local-preference to 250 for that prefix, in hopes that this would allow traffic destined for 1.1.1.0 go exclusively through the 13.0.0.0 segment between R3 and R1.   Unfortunately, even with this change, Bob noticed that traffic destined to 1.1.1.0 from our through AS23 still crossed on the link between R2 and R1.

Below are the configurations for R1, R2 and R3 along with the relevant show commands.

Can you assist Bob?   What can he do?  What did he do wrong, if anything?

Post your ideas and comments below!

R1:

version 12.4
hostname R1
interface Loopback0
 ip address 1.1.1.1 255.255.255.0
 ip ospf network point-to-point

interface FastEthernet0/0
 ip address 10.0.0.1 255.255.255.0
 ip ospf 1 area 1

interface FastEthernet1/0
 ip address 13.0.0.1 255.255.255.0
 ip ospf 1 area 1

router bgp 1
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.0 mask 255.255.255.0
 neighbor 10.0.0.2 remote-as 23
 neighbor 10.0.0.2 route-map PRE-PEND out
 neighbor 13.0.0.3 remote-as 23
 no auto-summary

ip prefix-list JUST-1.1.1.0 seq 5 permit 1.1.1.0/24

route-map PRE-PEND permit 10
 match ip address prefix-list JUST-1.1.1.0
 set as-path prepend 1

route-map PRE-PEND permit 20

R2:

version 12.4
hostname R2
interface FastEthernet0/0
 ip address 10.0.0.2 255.255.255.0
 ip ospf 1 area 1

interface FastEthernet0/1
 ip address 23.0.0.2 255.255.255.0
 ip ospf 1 area 1

router bgp 23
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.0.0.1 remote-as 1
 neighbor 23.0.0.3 remote-as 23
 no auto-summary
!

R3:

version 12.4
hostname R3
interface FastEthernet0/0
 ip address 13.0.0.3 255.255.255.0
 ip ospf 1 area 1

interface FastEthernet0/1
 ip address 23.0.0.3 255.255.255.0
 ip ospf 1 area 1

router bgp 23
 no synchronization
 bgp log-neighbor-changes
 neighbor 13.0.0.1 remote-as 1
 neighbor 13.0.0.1 route-map SET-LOCAL-PREF in
 neighbor 23.0.0.2 remote-as 23
 no auto-summary

ip prefix-list LOCAL-PREF-250 seq 5 permit 1.1.1.0/24

route-map SET-LOCAL-PREF permit 10
 match ip address prefix-list LOCAL-PREF-250
 set local-preference 250

route-map SET-LOCAL-PREF permit 20

Show commands R1:

R1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 1
BGP table version is 2, main routing table version 2
1 network entries using 120 bytes of memory
1 path entries using 52 bytes of memory
2/1 BGP path/bestpath attribute entries using 248 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory
BGP using 452 total bytes of memory
BGP activity 2/1 prefixes, 2/1 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.2        4    23      77      73        2    0    0 00:29:01        0
13.0.0.3        4    23      74      74        2    0    0 00:29:01        0

R1#show ip bgp
BGP table version is 2, local router ID is 1.1.1.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.0/24       0.0.0.0                  0         32768 i

R1#show ip route | begin resort
Gateway of last resort is not set

1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, Loopback0
23.0.0.0/24 is subnetted, 1 subnets
O       23.0.0.0 [110/2] via 13.0.0.3, 00:48:43, FastEthernet1/0
                 [110/2] via 10.0.0.2, 00:48:09, FastEthernet0/0
10.0.0.0/24 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, FastEthernet0/0
13.0.0.0/24 is subnetted, 1 subnets
C       13.0.0.0 is directly connected, FastEthernet1/0

Show commands R2:

R2#show ip bgp summary
BGP router identifier 2.2.2.2, local AS number 23
BGP table version is 14, main routing table version 14
1 network entries using 120 bytes of memory
2 path entries using 104 bytes of memory
3/1 BGP path/bestpath attribute entries using 372 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory
BGP using 676 total bytes of memory
BGP activity 1/0 prefixes, 4/2 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.1        4     1      73      77       14    0    0 00:29:07        1
23.0.0.3        4    23      71      73       14    0    0 01:04:54        1

R2#show ip bgp
BGP table version is 14, local router ID is 2.2.2.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.0/24       13.0.0.1                 0    250      0 1 i
*                   10.0.0.1                 0             0 1 1 i

R2#show ip route | begin resort
Gateway of last resort is not set

1.0.0.0/24 is subnetted, 1 subnets
B       1.1.1.0 [200/0] via 13.0.0.1, 00:28:37
2.0.0.0/24 is subnetted, 1 subnets
C       2.2.2.0 is directly connected, Loopback0
23.0.0.0/24 is subnetted, 1 subnets
C       23.0.0.0 is directly connected, FastEthernet0/1
10.0.0.0/24 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, FastEthernet0/0
13.0.0.0/24 is subnetted, 1 subnets
O       13.0.0.0 [110/2] via 23.0.0.3, 00:48:16, FastEthernet0/1
                 [110/2] via 10.0.0.1, 00:49:19, FastEthernet0/0

Show commands R3:

R3#show ip bgp summary
BGP router identifier 3.3.3.3, local AS number 23
BGP table version is 6, main routing table version 6
1 network entries using 120 bytes of memory
1 path entries using 52 bytes of memory
3/1 BGP path/bestpath attribute entries using 372 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory
BGP using 600 total bytes of memory
BGP activity 1/0 prefixes, 5/4 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
13.0.0.1        4     1      74      74        6    0    0 00:29:09        1
23.0.0.2        4    23      73      71        6    0    0 01:04:56        0

R3#show ip bgp
BGP table version is 6, local router ID is 3.3.3.3
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.0/24       13.0.0.1                 0    250      0 1 i

R3#show ip route | begin resort
Gateway of last resort is not set

1.0.0.0/24 is subnetted, 1 subnets
B       1.1.1.0 [20/0] via 13.0.0.1, 00:28:39
3.0.0.0/24 is subnetted, 1 subnets
C       3.3.3.0 is directly connected, Loopback0
23.0.0.0/24 is subnetted, 1 subnets
C       23.0.0.0 is directly connected, FastEthernet0/1
10.0.0.0/24 is subnetted, 1 subnets
O       10.0.0.0 [110/2] via 23.0.0.2, 00:48:18, FastEthernet0/1
                 [110/2] via 13.0.0.1, 00:48:48, FastEthernet0/0
13.0.0.0/24 is subnetted, 1 subnets
C       13.0.0.0 is directly connected, FastEthernet0/0

Best wishes,

Keith

And the answer is:

Thanks to you, and your 50+ posts, bob got his answer.   By reading your responses, Bob learned the following:

For R2, the BGP next hop for the best route, is still 13.0.0.1, even though it is learned from R3.     R3 doesn’t bother to change the next-hop attribute when learning routes via a eBGP neighbor (R1).    With R2 having 2 equal cost paths (OSPF) for the next hop of 13.0.0.1, R2 would load balance the traffic over the 10.0.0.0 and 23.0.0.0 networks for traffic going to 1.1.1.0/24

One solution would be to have R3 use next-hop-self for updates sent to R2.  Then R2 would see the next hop as 23.0.0.3, and all the traffic would be forwarded to R3 as desired.

The update on R3 would look like this:

router bgp 23
 neighbor 23.0.0.2 next-hop-self

This would cause R2, to have the BGP table of this:

R2#show ip bgp
BGP table version is 4, local router ID is 2.2.2.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.0/24       23.0.0.3                 0    250      0 1 i
*                   10.0.0.1                 0             0 1 1 i

Another option would be increasing the OSPF cost on R2’s 10.0.0.0/24 interface, so that it wouldn’t be considered an equal cost to get to 13.0.0.1 (the previous next hop before the change we just made).

Thanks everyone for all your assistance!    You rock.

Join us Friday, June 25th at 11AM Pacific / 2PM Eastern for another installment in the Open Lecture Series.

The topic that will be covered is Privilege Levels and Role Based CLI.

We look forward to seeing you there. Seats are limited.

• The QoS 5-Day Bootcamp is going to be quite a crowd! I look forward to catching up with old friends in that class. REMINDER: The Live Event starts at 11 AM EST each day beginning Monday, June 7th, 2010. Do not stress if you have to miss chunks of the Live Event due to your other life. Remember, you receive the class in recorded, interactive, and audio formats as well. Should you have questions during the recorded content, just email me directly. All versions will be ready for you the week following the Live Event.
• A quick shout out to the crew in the 2010 Summer Chicago 6 Day R&S bootcamp. Nice to see all of the Cisco employees in class, and thanks for not starting a brawl with the HP folks across the hall!
• Keith Barker and I just uploaded a new and important lesson in the Volume 2 Interactive Video Companion product. It is an interactive lesson on Troubleshooting. Troubleshooting what you might ask? Everyone’s favorite topic – Redistribution!!!!! Enjoy.
• More full labs walkthroughs are on the way for the Video Companion…we are waiting for an incredibly exciting re-release of Volume 2 that is happening very soon. Bug fixes, better explanations and verifications, and a full blown 2-hour Troubleshooting section in each lab. Wow!
• I re-sat the CCIE Written exam last week and I am adding practice exam questions still to Practice Exam 2 in the Written bootcamp. Many of the new Cisco questions were really pretty good and most of the good ones involved none other than Troubleshooting. Sure some questions are not so great and test trivia, but they were not of such a volume that they should be failing us, in my humble opinion.
• Thanks for reading my friends, and remember, Tech Knowledge, Strategy, Psychology, and Physical Wellness are your keys to success in these challenging Lab Exams. More and more students are asking me about study strategies and I will be sure to blog more on that soon.