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 19 – BGP network backdoor + RSVP + 3550 MAC Filtering

1,089 Words. Plan about 7 minute(s) to read this.

In the last NetMasterClass.com DOiT scenario 19 post, I concluded with this provocative statement: “I have more I want to blog about the BGP scenario, reserving bandwidth with RSVP, and some really interesting layer 2 filtering on the 3550.” After leaving everyone on tenterhooks for literally days now, I’m actually going to do it. Okay, maybe not leaving everyone. Well okay – probably not anyone! But I’m going to blog the info anyway. Try and stop me! :)

  • Let’s say you’ve got a multipoint hub-and-spoke frame-relay topology. And let’s assume that in this topology, the same IP address space is used, so that R1 = 192.168.100.1 = the hub, R2 = 192.168.100.2 = a spoke, and R3 = 192.168.100.3. And now let’s say that you’re going to make the 2 spokes (R2 & R3) eBGP peers. Now, you might think, “Same address space, one hop away, no problem. Throw in the neighbor statements and call it done.” Ah – but this is hub and spoke – the spokes can’t talk to one another directly. For R2 and R3 to talk to one another, they have to do it via the hub router, R1. So even though R2 and R3 are in the same address space, you’ll need to add an “neighbor ebgp-multihop” statement, as the R1 hub router is an additional hop.
  • Your BGP topology can create situations where a BGP-learned route causes a recursive routing problem, resulting in neighbor flapping and other issues.
    • To work around this, you can override the BGP-learned route with a “network backdoor” statement. When we think of network statements, we normally think of them as the way to originate a route into a routing protocol. If we want a route to get advertised into an IGP, the network statement is the simplest way to do that. But in the case of the BGP “network backdoor”, the network statement is NOT being used for network origination. Rather, it’s being used to tell the BGP router to prefer the IGP-learned route for that network, rather than the BGP-learned route. How does it do this? By assigning the BGP-learned route a distance of 200.
    • In this example, if BGP router R1 learns the prefix 4.4.4.0/24 from BGP, he’s going to prefer the IGP-learned route for 4.4.4.0/24 instead, because the BGP 4.4.4.0/24 will get an AD of 200.

      R1#show run | b router bgp
      router bgp 1
      bgp log-neighbor-changes
      neighbor 4.4.4.4 remote-as 4
      neighbor 4.4.4.4 ebgp-multihop 10
      neighbor 4.4.4.4 update-source Loopback1
      !
      address-family ipv4
      neighbor 4.4.4.4 activate
      no auto-summary
      no synchronization
      network 1.1.1.0 mask 255.255.255.0
      network 4.4.4.0 mask 255.255.255.0 backdoor
      exit-address-family
      !

      R1#show bgp ipv4 unicast
      BGP table version is 20, local router ID is 172.10.101.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
      r> 4.4.4.0/24 4.4.4.4 0 0 4 i
      *> 172.10.23.0/24 4.4.4.4 0 4 23 i

      R1#show ip route 4.4.4.0
      Routing entry for 4.4.4.0/24
      Known via “eigrp 100”, distance 90, metric 40640000, type internal
      Redistributing via eigrp 100
      Last update from 172.10.124.131 on Serial1/0, 5d15h ago
      Routing Descriptor Blocks:
      * 172.10.124.131, from 172.10.124.131, 5d15h ago, via Serial1/0
      Route metric is 40640000, traffic share count is 1
      Total delay is 25000 microseconds, minimum bandwidth is 64 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

      R1#

  • RSVP is a reservation protocol, where RSVP-capable applications can send RSVP messages to listening routers, and carve out a reserved chunk of bandwidth for themselves, end-to-end. The applications will have guaranteed bandwidth on all the routers they will need to get the traffic delivered. So, RSVP is simple in concept, but the syntax is arcane. Although to be fair, pretty much all IOS syntax is arcane, now isn’t it? If it wasn’t, they wouldn’t need to pay us so much. :)
    • The RSVP task was this: allocate reservable bandwidth of 60Kbps. Send a PATH message from R4 to R5 requesting that bandwidth be reserved for a telnet conversation with TCP source 172.10.43.4:5000 and destination 172.10.35.5:23. Make sure you have a single reservation for a Guaranteed Bit Rate of 5Kbps, allowing bursts of 2Kbps. Verify that the reservation has occurred with the “show ip rsvp reservation” command.
    • The solution is 3-fold. (1) Allocate the reservable bandwidth on all interfaces along the path by using “ip rsvp bandwidth” interface commands. What you’re doing here is carving out a chunk of pipe that could potentially be used by IP reservations. You’re saying, “Hey, let’s save this bit of bandwidth in case someone wants to reserve a part of it later.” (2) Simulate the RSVP “PATH” and “RESV” messages that normally applications would send by using “ip rsvp sender-host” and “ip rsvp reservation-host” commands. (3) You’re going to check all routers in the path with the “show ip rsvp reservation” command, to make sure that your reservation is working.In this example, we’ve got the reservation working between R4 and R5 via R3.

      R4#show run interface Serial0/0
      interface Serial0/0
      ip rsvp bandwidth
      end

      R4#show run interface Serial0/0.34
      interface Serial0/0.34 point-to-point
      ip rsvp bandwidth 60
      end

      R4#show run | i ip rsvp se
      ip rsvp sender-host 172.10.35.5 172.10.43.4 TCP 23 5000 5 2
      R4#

      R3#show run interf s0/0
      interface Serial0/0
      ip rsvp bandwidth 60
      end

      R3#show run interf s0/1
      interface Serial0/1
      ip rsvp bandwidth 60
      end

      R5#sho run interf s1/1
      interface Serial1/1
      ip rsvp bandwidth 60
      end

      R5#show run | i ip rsvp r
      ip rsvp reservation-host 172.10.35.5 172.10.43.4 TCP 23 5000 FF RATE 5 2

      R5#show ip rsvp reservation
      To From Pro DPort Sport Next Hop I/F Fi Serv BPS
      172.10.35.5 172.10.43.4 TCP 23 5000 172.10.35.5 FF RATE 5K
      R5#

  • The 3550 has the ability to do some interesting layer 2 filtering with MAC access-lists. We usually think of MAC access-lists for filtering specific layer 2 MACs. But like the layer 3 ACLs can filter certain types of traffic, the 3550 layer 2 ACLs can filter certain types of layer 2 traffic as well.
    • The task was to filter ethertype 8042 from entering VLAN20 and SNA traffic from VLAN10, but not to apply filtering to Catalyst switchports. Okay, fair enough – write a MAC access-list, then apply it to the VLAN with a VLAN filter. That’s a “can-do”, Sarge. Uh-huh…<sigh>
    • The ethertype 8042 was simple enough. SNA? I still haven’t dug up where NMC got their answer from. Anyone know where to find that SNA=”lsap 0x0 0xD0D”? Because I got nothin’. Anyway, here’s the code.

      CAT1#
      mac access-list extended ETYPE-8042
      permit any any etype-8042
      mac access-list extended PERMIT-ALL
      permit any any
      mac access-list extended SNA
      permit any any lsap 0x0 0xD0D
      !
      vlan access-map VLAN10 10
      action drop
      match mac address SNA
      vlan access-map VLAN10 20
      action forward
      match mac address PERMIT-ALL
      vlan access-map VLAN20 10
      action drop
      match mac address ETYPE-8042
      vlan access-map VLAN20 20
      action forward
      match mac address PERMIT-ALL
      !
      vlan filter VLAN10 vlan-list 10
      vlan filter VLAN20 vlan-list 20

NetMasterClass.com Scenario 20 scheduled for tomorrow.