BGP Regular Expressions

Posted by Jen on March 25, 2013
Posted in: BGP, CCIE, CCIE R&S, General. Leave a comment

Regular Expressions are something that I still struggle to wrap my head around.  However, they make things much easier and faster with parsing BGP tables, and they are of course unavoidable if you have to write an AS Path access-list.  WIth practice, they do of course get better.

To start, a table of regular expression characters and their meanings to fall back on (though it will be necessary to memorize these in the long run!):

Character

 Meaning
^ Start of String
$ End of String
[ ] Range of Characters
– Used to specify a range – ie [0-9]
( )

Logical Grouping
.

Any single character
* Zero or more instances
+ One or more instance
? Zero or one instance
_(underscore)

Comma, open or close brace, space, start of line or end of line

 

Using this table, some examples with both show commands and AS Path ACLs…

1) To view just prefixes originated in AS 100 with no other path:

show ip bgp regex ^100$

^ Start of String
100 Exactly AS 100
$ End of String

This will get you an output of just routes that originated from AS 100.

Corresponding AS Path ACL:

ip as-path access-list 99 permit ^100$

 2) Prefixes originated in a customer network of AS 100, which then pass through.  AS 100 will be your directly connected AS:

show ip bgp regex ^100_[0-9]+$

^ Start of String
100 Exactly AS 100
_ Space
[0-9] Any number 0-9
+ One or more instance of 0-9
$ End of line

Thus, this will match anything AS Path of 100 X, where X is any other single AS.

Corresponding AS Path ACL:

ip as-path access-list 99 permit ^100_[0-9]+$

 3) Prefixes which your AS learned directly from AS 100, were injected into BGP by AS 300, and passed through AS 200 somewhere along the way (not limited to only passing through AS 200):

show ip bgp regex ^100_(.+_)*200_(.+_)*300$

^ Start of String
100 Exactly AS 100
_ Space
(.+_) One or more instance of any single character, space
* Zero or more instances
200 Exactly AS 200
_ Space
(.+_) One or more instance of any single character, space
* Zero or more instances
300 Exactly AS 300
$ End of Line

Corresponding AS Path ACL:

ip as-path access-list 99 permit ^100_(.+_)*200_(.+_)*300$

This one looks long and confusing, but when you imagine that it is simple a path of AS 100 200 300 with the option of any AS of any character between 100 and 200 and 200 and 300, it’s not so bat.  Remember to use a * for zero or more instances when you want to leave the option open for NO other AS in the path – it’s the best choice to also leave the option open for just 100 200 300.

Regular expressions really just require practice.  Two websites that I use for practice quizzes (and find that I do not memorize the answers – too many characters) are linked below.

http://catspace.com/goodies/regexp.htm

http://www.netcraftsmen.net/presos/Regex_Practice/player.html

Enjoy!

OSPF Loopback Network Type

Posted by Jen on August 27, 2012
Posted in: CCIE, CCIE R&S. Leave a comment

If I had to pick a favorite protocol, it would have to be OSPF. OSPF is badass. It does a million cool things, and because I am pretty Type-A OCD, I love how organized it is. How can the hierarchy and structure of OSPF not scratch the worst OCD itch?

It’s also kinda cranky and complicated sometimes, with some quirks that can cause some real hangups. One such quirk, which I have recently come across in my CCIE studies, is the Loopback network type. Loopback interfaces are not only functional to OSPF (and other protocols and network management systems) for a variety of reasons, they’re also useful to have in a lab environment. You can inject routes that wouldn’t otherwise be there by having a bunch of loopbacks. But this can introduce other problems into the environment without careful consideration.

OSPF has several different network types…Broadcast, Non-Broadcast, Point-to-Point, etc. Loopback is another network type, and just like the rest, certain kinds of interfaces will default to certain types. It is also a configurable value, just like the rest. An Ethernet interface, for example, may default to Broadcast, but it can be changed to Non-broadcast, or Point-to-Multipoint, or whatever fits your given scenario. It is no different with the loopback type, and in a few cases it is advisable.

One such case may be the advertisement of masks. Regardless of the mask length configured on a loopback interface, if the interface is left with the default network type of Loopback, the mask will be advertised as a /32 host route. So if the address of the loopback has a native mask of /24, it will appear in the routing table as a /32.

This is fine in most production cases, though it can cause problems with MPLS L3VPNs and label bindings when OSPF is used as the IGP on the backbone. In a lab scenario, this could be problematic if a loopback is the way certain routes are being injected and the expectation is that the native mask will be advertised. See the following example using Loopback10 on R2, advertised into Area 0 as a /24:

Topology

R2#sh run int loopback10
!
interface Loopback10
ip address 10.10.10.1 255.255.255.0
end
!
R2#sh ip ospf interface loopback0
Loopback0 is up, line protocol is up
Internet Address 150.1.2.2/24, Area 0
Process ID 1, Router ID 150.1.2.2, Network Type LOOPBACK, Cost: 1
Loopback interface is treated as a stub Host
!
R2#sh run | b router ospf 1
router ospf 1
router-id 150.1.2.2
log-adjacency-changes
network 10.10.10.0 0.0.0.255 area 0
network 150.1.2.2 0.0.0.0 area 0
network 155.1.0.2 0.0.0.0 area 0
network 155.1.23.2 0.0.0.0 area 0
!

Yet on R3, the route is in the table as a /32 host route, despite its native mask of /24:

R3#sh ip route 10.10.10.0
% Subnet not in table
!
R3#sh ip route 10.10.10.1
Routing entry for 10.10.10.1/32
Known via “ospf 1”, distance 110, metric 65, type intra area
Last update from 155.1.23.2 on Serial0/2/1, 00:07:18 ago
Routing Descriptor Blocks:
* 155.1.23.2, from 150.1.2.2, 00:07:18 ago, via Serial0/2/1
Route metric is 65, traffic share count is 1
!

If it is a requirement to advertise the native mask, one solution is to change the OSPF network type of the loopback interface. Here I used the Point-to-Point network type:

R2(config)#interface loopback10
R2(config-if)#ip ospf network point-to-point
R2(config-if)#exit
R2(config)#
!
R2#sh ip ospf interface loopback10
Loopback10 is up, line protocol is up
Internet Address 10.10.10.1/24, Area 0
Process ID 1, Router ID 150.1.2.2, Network Type POINT_TO_POINT, Cost: 1
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Supports Link-local Signaling (LLS)
Index 4/4, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 0
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
!

Now, on R3, the native mask appears in the routing table:

R3#sh ip route 10.10.10.0
Routing entry for 10.10.10.0/24
Known via “ospf 1”, distance 110, metric 65, type intra area
Last update from 155.1.23.2 on Serial0/2/1, 00:01:53 ago
Routing Descriptor Blocks:
* 155.1.23.2, from 150.1.2.2, 00:01:53 ago, via Serial0/2/1
Route metric is 65, traffic share count is 1
!
R3#sh ip route 10.10.10.1
Routing entry for 10.10.10.0/24
Known via “ospf 1”, distance 110, metric 65, type intra area
Last update from 155.1.23.2 on Serial0/2/1, 00:01:59 ago
Routing Descriptor Blocks:
* 155.1.23.2, from 150.1.2.2, 00:01:59 ago, via Serial0/2/1
Route metric is 65, traffic share count is 1

Frame Relay Switching

Posted by Jen on August 10, 2012
Posted in: CCIE, CCIE R&S. Leave a comment

I had some pretty poor timing when I decided I wanted to take on this whole CCIE thing.  Busy times at work etc, but surely I could shoehorn Lab study in there somewhere (can you hear my sarcasm via the interwebs?).  But I’ve wanted this since I knew what a router was, so on we go…and on…and on…

But there’s one other reason it was poor timing – Frame Relay.  My guess is if I had waited another couple of years it would have been dropped from the exam entirely. But I’m not a patient person, I want my CCIE, and I want it now. So Frame Relay it is.  I uhm…don’t like Frame Relay too much.  At all.  But what doesn’t kill you makes you stronger, right?

So a topic that I stumbled with at first, since I have always done Frame from the CE point of view – Frame Relay Switching, a newer CCIE R&S topic in the last couple of years.  It is an easy one to lab up and test in a three router topology using back-to-back Frame Relay – no need to build out a Frame Cloud.

Topology using R3 as the Frame Relay Switch

In this topology, R3 is playing the role of the frame-relay switch, with R1 and R2 as the clients using DLCI 103 and 203 respectively.  To begin, R3 must have frame relay switching enabled globally:

R3(config)#frame-relay switching

Once switching has been enabled, the router’s interface type can be set to DCE (the default is DTE) so that it can respond to LMI queries and pass on DLCI information to R1 and R2.  If frame-relay switching is not enabled prior to setting the interface type, an error message stating “Must enable frame-relay switching to configure DCE/NNI” will be generated. Clocking will need to be configured, and of course Frame Relay encapsulation must be enabled on both interfaces facing R1 and R2:

R3#show run int serial0/2/0

!
interface Serial0/2/0
description to R1 S0/3/1
no ip address
encapsulation frame-relay
clock rate 2000000
frame-relay intf-type dce
!

R3#show run int serial0/2/1

!
interface Serial0/2/1
description to R2 S0/0/1
no ip address
encapsulation frame-relay
clock rate 2000000
frame-relay intf-type dce
end

Likewise, R1 and R2 must have their interfaces configured for frame-relay encapsulation, as well as their assigned IP addresses:

R1#sh run int s0/3/1
!
interface Serial0/3/1
description R3 S0/2/0
ip address 172.16.10.1 255.255.255.0
encapsulation frame-relay
end
R1#

R2#sh run int s0/3/1
!
interface Serial0/0/1
description R3 S0/2/1
ip address 172.16.10.2 255.255.255.0
encapsulation frame-relay
end

In this scenario, no DLCIs are locally terminated on R3 – they will be switched to other Frame Relay ports, specifically between R1 and R2.  There are two methods that can be used to accomplish this.  The frame-relay route interface-level command, which is a legacy command, or the globally configured connect command.  First, using the frame-relay route command, the incoming DLCI on an interface must be statically mapped to an outgoing interface and outgoing DLCI, and then configured in reverse:

R3#sh run int s0/2/0

!
interface Serial0/2/0
description to R1 S0/3/1
no ip address
encapsulation frame-relay
clock rate 2000000
frame-relay intf-type dce
 frame-relay route 103 interface Serial0/2/1 203
end

R3#sh run int s0/2/1
!
interface Serial0/2/1
description to R2 S0/0/1
no ip address
encapsulation frame-relay
clock rate 2000000
frame-relay intf-type dce
 frame-relay route 203 interface Serial0/2/0 103
end

Once this has been configured, switched PVCs should become active on R3:

R3#show frame-relay pvc

PVC Statistics for interface Serial0/2/0 (Frame Relay DCE)

Active     Inactive      Deleted       Static
Local          0            0            0            0
Switched       1            0            0            0
Unused         0            0            0            0

DLCI = 103, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial0/2/0
….[output omitted]…
PVC Statistics for interface Serial0/2/1 (Frame Relay DCE)

Active     Inactive      Deleted       Static
Local          0            0            0            0
Switched       1            0            0            0
Unused         0            0            0            0

DLCI = 203, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial0/2/1
….[output omitted]…

Connectivity can be further verified on both R1 and R2 with show frame-relay pvc, show frame-relay map, and a ping test:

R1#show  frame-relay  pvc

PVC Statistics for interface Serial0/3/1 (Frame Relay DTE)

Active     Inactive      Deleted       Static
Local          1            0            0            0
Switched       0            0            0            0
Unused         0            0            0            0

DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/1
….[output omitted]…

R1#show frame-relay map
Serial0/3/1 (up): ip 172.16.10.2 dlci 103(0x67,0x1870), dynamic,
broadcast,, status defined, active

R1#ping 172.16.10.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R1#
On R2:

R2#show  frame-relay  pvc

PVC Statistics for interface Serial0/0/1 (Frame Relay DTE)

Active     Inactive      Deleted       Static
Local          1            0            0            0
Switched       0            0            0            0
Unused         0            0            0            0

DLCI = 203, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/1

….[output omitted]…

R2#show frame-relay map
Serial0/0/1 (up): ip 172.16.10.1 dlci 203(0xCB,0x30B0), dynamic,
broadcast,, status defined, active

R2#ping 172.16.10.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

The second method, using the global connect command, can be configured as follows:

R3(config)# connect R1_switched_R2 Serial0/2/0 103 Serial0/2/1 203

Once completed, the same verification tools can be used again on R3, R1 and R2:

R3#show frame-relay pvc

PVC Statistics for interface Serial0/2/0 (Frame Relay DCE)

Active     Inactive      Deleted       Static
Local          0            0            0            0
Switched       1            0            0            0
Unused         0            0            0            0

DLCI = 103, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial0/2/0
….[output omitted]…
PVC Statistics for interface Serial0/2/1 (Frame Relay DCE)

Active     Inactive      Deleted       Static
Local          0            0            0            0
Switched       1            0            0            0
Unused         0            0            0            0

DLCI = 203, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial0/2/1
….[output omitted]…

On R1:

R1#show  frame-relay  pvc

PVC Statistics for interface Serial0/3/1 (Frame Relay DTE)

Active     Inactive      Deleted       Static
Local          1            0            0            0
Switched       0            0            0            0
Unused         0            0            0            0

DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/1
….[output omitted]…

R1#show frame-relay map
Serial0/3/1 (up): ip 172.16.10.2 dlci 103(0x67,0x1870), dynamic,
broadcast,, status defined, active

R1#ping 172.16.10.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R1#
On R2:

R2#show  frame-relay  pvc

PVC Statistics for interface Serial0/0/1 (Frame Relay DTE)

Active     Inactive      Deleted       Static
Local          1            0            0            0
Switched       0            0            0            0
Unused         0            0            0            0

DLCI = 203, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0/1

….[output omitted]…

R2#show frame-relay map
Serial0/0/1 (up): ip 172.16.10.1 dlci 203(0xCB,0x30B0), dynamic,
broadcast,, status defined, active

R2#ping 172.16.10.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

Cisco Live 2012!

Posted by Jen on June 19, 2012
Posted in: Cisco Live. 3 Comments

Cisco Live…where do I start?  This was my first year attending Networkers, though I have wanted to go since I knew what it was.   It far exceeded my expectations, and they were pretty high.  San Diego couldn’t have been a better venue for my first forray.  It’s an easy city to navigate, not to mention it’s beautiful (understatement).  The Convention Center was directly across from my hotel, can’t beat a quick walk…especially when you’ve already overslept for the 8am class…again!

I felt like the whole city was decked out in Cisco Live gear!  I may have also decked myself out at the store. ;)  I came in early on Saturday so I could register and find my way around, since I was scheduled to take the CCIE R&S Written on Sunday afternoon.  Registration and material pickup were a breeze.

I think for any professional in this field, there is no better opportunity to meet your peers.  I still can’t get over how many people I got to meet from all over the world, in every segment of networking.  And the best part was, everyone was excited to be there and talk about what they did at home, what they were into, etc.  Possibly we talked all night, on a few occasions (see late to 8am classes above ;) ).  To me, it was almost like being in Cisco college for a week…meet new friends (17,000 new friends!), go to class at the crack of dawn (I am NOT a morning person), party all night, do it again the next day.  It’s also possible I needed a few days to recover. ;)

The sessions – out of this world.  It would take me hours to go into each one of them, but the standouts for me were as follows.  If you went to San Diego or have access to the PDFs, I highly recommend downloading the class material.

  • Highly Available Wide Area Network Design – David Prall  – This was my first day, and it was a knockout.  We are fortunate enough to work with David on occasion since he’s here in DC as well.  He’s truly one of the best, and also one of the coolest guys ever.  His class focused on optimization of WAN environments, and though ours is small, I picked up a lot of excellent information here that applies to any network.  A lot of the information was new to me, so this was a great start to the week.  David was also a great speaker with some excellent case-study type examples.
  • Mastering Data Center QoS – Lucien Avramov– This session focused on QoS for the Nexus family, which is of course near and dear to my heart. ;)  I mean, I do love all things Nexii.  My QoS skills (not fabulous to begin with) haven’t been exercised much beyond CCIE study, so this was awesome for me.  Like many engineers, I usually associate QoS with VoIP and video, but Lucien really brought to my attention how beneficial QoS can be in the Data Center for other traffic (Storage in particular).  As we are in the process of standing up several new deployments, I was thrilled with this perspective, and am very excited to implement some of Lucien’s ideas.  He also did an excellent job of helping us understand how to offer QoS for Data Center at the same time as VoIP and Video, and make it all work together.  Fun, engaging session.
  • Routed Fast Convergence and High Availability – Denise Fishburne – Denise was awesome; this was a great session.  As someone who is in the process of a core re-design effort, this one gave me a *lot* to think about, especially paired with David’s session.  Her “Culture of High Availability” was a great concept, and really helps to think about what engineers want to design towards.  The big picture of high availability (even outside the routed protocols) along with coverage of NSF, BFD, and timer tweaking where appropriate definitely sent me home itching to rethink a few of my plans.
  • Troubleshooting BGP – Daniel Walton – Last session on the last day, and I’m glad this was it.  Dan definitely kept my attention the whole time, despite a flight out a few hours later.  As someone whose perspective of BGP has been almost entirely from the CE side of the house, this was great.  I’ve had a foray into iBGP in a VRF-Lite environment, but this filled in a lot of gaps for me, especially going into the CCIE Lab study.  What was great is that everything Dan covered was absolutely useful, much of it for general troubleshooting and not just BGP.  I especially liked his coverage of Bestpath selection and Table Version troubleshooting; things I had not yet gotten to see.  Very helpful!  Great end to the week.

Other home runs at Cisco Live:

  • Mobility – Cisco’s conference iPhone/iPad app was awesome.  I lived by it the whole week.  Being able to use my phone to see where I was going next, move classes around, and find out the schedule for the day definitely helped.  Also the ability to download PDFs and follow along during the sessions.  When you’re short and can’t see the screen over 100+ people, this is key.
  • Organization – I can’t believe they managed to pack 17,000 people into one convention center, feed us, get us from session to session, and still never feel like we were a total herd of cats was unbelievable.
  • World of Solutions – Not only did I get to meet up with some excellent vendors and shop around for some products we may need, but Cisco’s own demos were fantastic.  I got to see a lot of technology with which I don’t often get to interact.  Fantastic.
  • Customer Appreciation Party – They rented out Padre Stadium.  Seriously?  That was pretty incredible.  As a huge baseball fan, I was thrilled to be running around on MLB grass.  But Weezer, food, beer fireworks.  Yes please!
  • Mythbusters Closing Keynote – I mean, you just can’t say anything more than Mythbusters.  Awesome.

What a week.  I’m still coming down from the high of being there, and I left five days ago.  Can’t wait for Cisco Live 2013 in Orlando!

Whoa.

Posted by Jen on June 18, 2012
Posted in: General. 2 Comments

I just bought Nexiilicious.com.  This  might be the most amazing thing ever.  After I get this puppy working, Cisco Live recap on its way.  Oh yeah…hello, world. :)