From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

NMC DOiT Vol.2 Scenario 24 – Multilink Frame Relay + frame-relay map bridge + switchcore wirespeed-store + BGP Well-Known Communities + BGP ORF (Outbound Route Filtering) + BGP Conditional Route Injection + BGP Multicast

1,393 Words. Plan about 9 minute(s) to read this.

I wound my way through NetMasterClass.com DOiT Vol.2 scenario 24 yesterday. I was able to complete it in 8 hours, taking my time. I really made it a point to go slowly through the tasks I was having trouble with, hammering on the debugs and show commands to be sure I really understood what was going on. The lab was not task-intensive; there was no QoS. On the other hand, there were some of the tasks were “out there” and took time to accomplish because I’d never run into them before.

  • There is a standard for Multilink Frame Relay (FRF.16). I guess there’s no excuse to have NOT known about it, as it’s right there in the Doc CD (which clearly I haven’t yet spent enough time with). But it was a new one on me. This scenario had you bring up a frame link in such a way that a new serial connection could be bundled with the existing one. MLPPP was not allowed, thus leaving MFR as the solution.
  • This scenario built a topological triangle of links between three routers, all part of the same bridge group. One link was back-to-back frame using MFR. One was PPP. One was “traditional” frame. I’m pretty comfortable with IRB concepts, so this wasn’t intimidating by itself. The problem I had was that I couldn’t get the “traditional” frame-relay links to participate in the bridge. It just seemed like all the traffic was getting dropped. Long story short, doing a “show spanning-tree” on the routers showed me that all 3 routers were forwarding on all bridge links, which I knew clearly couldn’t be true. I also noticed that one of the routers saw the root bridge across the wrong port. So, I narrowed the problem down to this frame-link, and shut down the other links to isolate it. Then I cranked up a “debug frame-relay packet” and saw that encaps for bridge-sourced traffic heading across that link were failing. Checking “show spanning-tree” again confirmed that the 2 routers remaining in the topology weren’t talking via the bridge, as both routers claimed to be root bridge. I was missing a key command on my frame interfaces: frame-relay map bridge. Once I put that in, the link began to function properly as a member of the bridge.
  • An odd little task that popped up was to configure a 3550 “to reserve bandwidth for buffer storage to accommodate broadcast and multicast storms.” I figured this was one of the ones I hadn’t run into before, so I started to browse through the 3550 command list on the Doc CD. In a few minutes, I’d discovered “switchcore wirespeed-store” that met the requirements. Again, that illustrates the value of knowing one’s way around the Doc CD come lab time.
  • I missed one major piece of the BGP configuration because I didn’t let one of the tasks sink into my head before I started configuring. The requirement was that “BGP neighbors must communicate until the last available path between them is gone.” What that means is that they want you to peer your BGP neighbors using loopbacks. That way, if physical links go down, the BGP neighbors will stay peered. But I didn’t quite “get it” until I’d already configured all my neighbors (and there was a lot of them) using physical interfaces, and then fully pondered the implications of that requirement. I guess I should have yanked it all out and started again, but I didn’t. Instead, I opted to continue on with the rest of the BGP tasks.
  • Another BGP command that popped up here was “set community local-as additive“, which sets the local-as community on the advertisement. The “additive” keyword means to preserve whatever community attributes might already be there, adding the new one. If you’re not sure what the “local-as” community does, it’s one of the 4 well-known BGP communities.
  • Another BGP command that showed up was the ability of one BGP router to send another BGP router a list of routes it doesn’t want to get. The other router actually does the filtering. So if router R3 doesn’t want to get certain prefixes from R1 and R2, R3 can send a prefix-list to R1 and R2. R1 & R2 therefore won’t send those prefixes to R3. The magic here is the “neighbor capability orf prefix-list“. Check out the code below, edited to just point out the outbound route-filter (ORF) related configuration between R3 & R2. Note on R2 his full BGP tables, versus what he actually sends to R3.

    R3#show run | b router bgp
    router bgp 65001
    neighbor 145.11.20.2 remote-as 65001
    !
    address-family ipv4
    neighbor 145.11.20.2 activate
    neighbor 145.11.20.2 capability orf prefix-list send
    neighbor 145.11.20.2 prefix-list ORF in
    exit-address-family

    ip prefix-list ORF seq 5 deny 192.168.1.0/24
    ip prefix-list ORF seq 10 deny 192.168.2.0/24
    ip prefix-list ORF seq 15 deny 192.168.3.0/24
    ip prefix-list ORF seq 20 permit 0.0.0.0/0 ge 1

    R2#show run | s router bgp
    router bgp 65001
    neighbor 145.11.20.3 remote-as 65001
    neighbor 145.11.20.3 capability orf prefix-list receive

    R2#show ip bgp
    BGP table version is 41, local router ID is 145.11.102.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
    *>i192.168.0.0/16 145.11.20.3 0 100 0 i
    *> 192.168.1.0 145.11.25.10 0 1000 600 ?
    *> 192.168.2.0 145.11.25.10 0 1000 600 ?
    *> 192.168.3.0 145.11.25.10 0 1000 600 ?
    *> 192.168.4.0 145.11.25.10 0 1000 600 ?
    *> 192.168.5.0 145.11.25.10 0 1000 600 ?
    *> 192.168.6.0 145.11.25.10 0 1000 600 ?
    *> 192.168.7.0 145.11.25.10 0 1000 600 ?
    *> 192.168.8.0 145.11.25.10 0 1000 600 ?
    *> 192.168.201.0 145.11.25.10 0 1000 600 ?
    *> 192.168.202.0 145.11.25.10 0 1000 600 ?
    *> 192.168.203.0 145.11.25.10 0 1000 600 ?

    R2#show ip bgp neighbor 145.11.20.3 advertised-routes
    BGP table version is 41, local router ID is 145.11.102.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
    *> 192.168.4.0 145.11.25.10 0 1000 600 ?
    *> 192.168.5.0 145.11.25.10 0 1000 600 ?
    *> 192.168.6.0 145.11.25.10 0 1000 600 ?
    *> 192.168.7.0 145.11.25.10 0 1000 600 ?
    *> 192.168.8.0 145.11.25.10 0 1000 600 ?
    *> 192.168.201.0 145.11.25.10 0 1000 600 ?
    *> 192.168.202.0 145.11.25.10 0 1000 600 ?
    *> 192.168.203.0 145.11.25.10 0 1000 600 ?

    Total number of prefixes 8

  • BGP conditional route injection – bgp inject-map – was also covered in this scenario. The configuration guide for this task is thorough, but I needed to read through it a couple of times to understand how the different prefix-lists that are used help the router make a decision about what is to be injected.
  • The last task I wanted to mention from this scenario was using BGP to solve a multicast RPF problem. The way the multicast task was laid out, there would be an RPF failure, causing one of the two PIM dense-mode routers with interfaces that had joined the group to not respond to a ping from the multicast source. To overcome the RPF problem, multicast BGP was used to advertise the multicast source via a new interface. A good example of this code can be found here. Also take a look at the code example below, where R5 is advertising a multicast source to R3, and then how R3’s mroute table for the group 229.1.1.1 looks once the multicast traffic starts to flow through the tree.

    R5#show run | b router bgp
    router bgp 65002
    neighbor 145.11.20.3 remote-as 65001
    !
    address-family ipv4 multicast
    redistribute connected metric 1 route-map CONN->BGPMULTICAST
    neighbor 145.11.20.3 activate
    exit-address-family

    !
    route-map CONN->BGPMULTICAST permit 10
    match interface FastEthernet0/0.30

    !
    R5#show run interf fa0/0.30
    Building configuration…

    Current configuration : 124 bytes
    !
    interface FastEthernet0/0.30
    encapsulation dot1Q 30 native
    ip address 145.11.45.5 255.255.255.0
    ip pim dense-mode
    end

    R3#show run | b router bgp
    router bgp 65001
    neighbor 145.11.20.5 remote-as 65002
    !
    address-family ipv4 multicast
    neighbor 145.11.20.5 activate
    exit-address-family

    !
    R3#show ip bgp ipv4 multicast
    BGP table version is 2, local router ID is 145.11.103.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
    *> 145.11.45.0/24 145.11.20.5 0 100 0 (65002) ?

    R3#show ip mroute
    IP Multicast Routing Table
    Flags: D – Dense, S – Sparse, B – Bidir Group, s – SSM Group, C – Connected,
    L – Local, P – Pruned, R – RP-bit set, F – Register flag,
    T – SPT-bit set, J – Join SPT, M – MSDP created entry,
    X – Proxy Join Timer Running, A – Candidate for MSDP Advertisement,
    U – URD, I – Received Source Specific Host Report,
    Z – Multicast Tunnel, z – MDT-data group sender,
    Y – Joined MDT-data group, y – Sending to MDT-data group
    Outgoing interface flags: H – Hardware switched, A – Assert winner
    Timers: Uptime/Expires
    Interface state: Interface, Next-Hop or VCD, State/Mode

    (*, 229.1.1.1), 22:37:27/stopped, RP 0.0.0.0, flags: DCL
    Incoming interface: Null, RPF nbr 0.0.0.0
    Outgoing interface list:
    Loopback103, Forward/Dense, 22:37:27/00:00:00
    BVI1, Forward/Dense, 22:37:02/00:00:00

    (145.11.45.7, 229.1.1.1), 00:00:05/00:02:58, flags: LT
    Incoming interface: BVI1, RPF nbr 145.11.20.5, Mbgp
    Outgoing interface list:
    Loopback103, Forward/Dense, 00:00:06/00:00:00

    (*, 224.0.1.40), 22:37:56/00:02:49, RP 0.0.0.0, flags: DCL
    Incoming interface: Null, RPF nbr 0.0.0.0
    Outgoing interface list:
    BVI1, Forward/Dense, 22:37:56/00:00:00