Archive for the ‘cisco’ Category
My Schedule for Cisco Live 2013
I’m all set up to go to Cisco Live in Orlando this year. Good thing, too, since I couldn’t make it to San Diego last time. It’ll be a great and fun time as usual, and I’m quite excited.
As it turns out, ARRL Field Day happens to be the weekend leading up to the festivities. I’ve been in contact with the local Orlando club, and they say the attendees are more than welcome to join them. They are meeting at the City of Orlando Emergency Operations Center, which is about 20 minutes away from the Convention Center.
Anyway, here’s my schedule for the week.
Saturday, 22 June 14:00 : Field Day begins and runs for 24 hours. 17:00 : I'll make my way over to Field Day for a few hours. Sunday, 23 June Open Monday, 24 June 08:00 : CCIE R&S Written (again) 10:00 : BRKARC-3437 - Cisco Catalyst 3750 / 3560 and 2960 Series Switching Architecture 13:00 : BRKARC-2013 - Cisco Nexus 3548 Switch Architecture 15:30 : GENSK-1294 - Enterprise Network Keynote: Getting You Where You Want to Go Tuesday, 25 June 08:00 : BRKDCT-2218 - Scalable Midsize Data Center Designs 10:00 : GENKEY-1295 - KEYNOTE: Tomorrow Starts Here 12:30 : BRKSEC-3021 - Maximizing Firewall Performance 15:00 : BRKSEC-2020 - Firewall Deployment Wednesday, 26 June 08:00 : BRKSEC-1050 - Are you choosing the right VPN technology for your network? 10:00 : GENKEY-1296 - KEYNOTE: Unlocking the Value of Innovation 13:30 : BRKIPM-2264 - Multicast Troubleshooting 16:00 : BRKRST-2041 - WAN Architectures and Design Principles Thursday, 27 June 08:00 : BRKRST-2513 - QoS Design For IPSec VPNs 10:00 : BRKSEC-2691 - Identity Based Networking: IEEE 802.1X and Beyond 12:30 : BRKCRS-3090 - Implementing Network Automation 14:30 : GENKEY-1297 - Celebrity Closing Keynote 16:00 : BRKSEC-2014 - Identifying and Mitigating Network Threats Friday, 28 June Unknown : Leave for home
Does this mean I’m actually going to attend over a dozen classes? Probably not. I’ve got to save some time for socializing and exploring the World of Solutions.
Send any Game of Thrones premiers questions to me.
JNCIS – Epic Win (Again)
I spent the last of my Juniper exam vouchers on the JNCIS-SEC exam and passed by the skin of my teeth today. Since I took a new job last month that’s 100% Cisco, this is the last Juniper exam I’ll take for the foreseeable future. Too bad, too. I really like the Juniper exams.
At my previous job, we were 90% Juniper with a whole mess of SRX firewalls around the world. Since this exam is really about that platform, it was pretty logical that I should do alright on it. Of course, a large part of the blueprint was on IDS and UTM, and I have no experience there. For my entire career, those type of devices have been handled by other groups, so I had some studying to do. That’s where I ran into problems. I have absolutely no interest in IDS. I have no interest in UTM. There’s nothing about content scanning and analysis that interests me at all. I promise you all that I tried my best to read up on these topics, but I was asleep after 10 words every time I tried. After rescheduling the exam twice to try and study a bit more, I finally decided it wasn’t worth the trouble and just took the exam…and passed.
The exam was typical Juniper with clearly-worded questions and perfectly-clear exhibits all around. A near-perfect exam yet again from Juniper. I was disappointed by three questions, though. The problem wasn’t with the technical details; they were just worded terribly. I’m definitely not shy about commenting on questions during the exam, so hopefully the exam team can use my comments to improve those bad apples. I’ll miss these exams; Cisco surely doesn’t produce any exam of this quality.
Send any Final Four tickets questions my way.
A Little Story on Switch Configuration
Here’s another story from the late night. I’ve changed the details to protect the innocent, but you’ll get the idea.
I think most of you know that I started a new job late last year, and I’ve spent my waking hours getting caught up on how the new company works, how everything fits together, and all that jazz. One of the big reasons that I (and a number of others) were brought in was to fix the biggest problem; the company doesn’t have a real central control over customer-facing technologies. There’s a group that does central IT for the company (Exchange, SharePoint, Oracle apps, etc.), but there are dozens and dozens of applications out there. That means there are dozens of “network teams” around the world doing their own thing.
One of those groups gave me a call the other day for some help. Their stack of old 2950s was having some issues, and they needed my help to figure out what was going on. Among the symptoms were flapping interfaces on the firewall and – the best of all – every command was greeted with an memory error. Want to see the config? Too bad. Want to see the memory utilization? Too bad. How about configure the thing? Too bad. The only command that I could actually get to work was a show version, but that’s pretty pointless when trying to troubleshoot issues.
So, what did I find? Nothing that could help with the problem, but plenty of stuff to fix. Bascially, the switch has VLAN 1, it’s layer-3 interface, and a single username configured. Nothing else. The configuration items that I consider to be basic just weren’t there thanks to the group’s network guy being a jack of all trades and master of none. Does putting every host on VLAN1 work? Sure it does. Would you just turn on your switch and not configure anything? I hope not. Does someone who does networking part-time thing it’s a problem? Obviously not.
So, what was missing? For starters, there was no syslog server configured (or even existed on the network at all). That’s a problem since the only way that I could see the logs was to reboot the switch and try again. What did the logs say when I finally rebooted the guy? Nothing since the buffer is empty, but the logs for the boot messages started with “1h3m” by the time I got back to it. That means the service timestamps commands for logging were missing. That lead me to ask what the time was on the box. Did you guess it was March 1, 1993? Yeah – no NTP server set, either. Without these basic configuration items, the odds of doing any troubleshooting are just about zero. Actually, they are zero in this case. The basics were missing, and now we have no idea what the real cause of our problems was.
I found a whole mess of other issues, too. The second switch was connected over an access port. No password encryption service. Both switches were unconfigured VTP servers. Not a single interface description. My OCD definitely kicked in that day.
I guess I’ll have to work for my paycheck this week.
VRF-Aware IPSec Tunnels
Man, time is hard to come by of late. I’ve had so little time to rest that’s it’s hard to get my thoughts together. It’s a good thing in this case, though, since it’s my fantastic job that’s taking all my time. It’s great to see new network and learn their internals…especially when they were designed by some long-time CCIEs who actually knew what they were doing.
One of the big things that I’m dealing with lately is VRFs. I’ve implemented some VRF-lite stuff, but I’ve never had any practical experience with the full force of them. I’m definitely learning here. Since the blog here is really about my sharing what I’ve learned, let’s go through something that came up recently – terminating VPNs on one VRF while passing traffic to another.
What I’m talking about is the old-school, static IPSec VPNs that we’ve all configured a million (or so) times. You know the ones with crypto maps applied to interfaces? Well, we’re going to configured one of those for the VRF called “CUSTOMER1″ terminated on an interface in the “INTERNET” VRF.
There’s some terminology for these VRFs, actually. The INTERNET VRF, which has the tunnel endpoint is called the front VRF (FVRF); CUSTOMER1 is called the internal VRF (IVRF). I’ll try to remember to use those terms, but I make no promises.
First, we need to create the VRFs themselves. Since the endpoints are in two different VRFs, we’ll need to have some routes leaked from the IVRF to the FVRF. I could write 847829843828 words on route leaking and not cover everything in my limited experience, so you’ll have to look that up on your own if you don’t know what I’m talking about. Route-target 65000:1 is exported from INTERNET and imported into CUSTOMER1
ip vrf INTERNET rd 65000:1 route-target export 65000:1 ! ip vrf CUSTOMER1 rd 65000:101 route-target import 65000:1
At this point, we just put the interfaces in the right VRF along with their addresses. We’ll also configure an ISAKMP policy just like we’ve done a million times.
crypto isakmp policy 100 encr aes authentication pre-share group 2 ! interface Ethernet0/0 ip vrf forwarding INTERNET ip address 192.0.2.1 255.255.255.0 ! interface Ethernet0/1.1 encapsulation dot1Q 1 ip vrf forwarding CUSTOMER1 ip address 192.168.201.1 255.255.255.0
Next we’ll create a keyring that’s referenced by the IVRF. This will make the key for the remote end available for use by that VRF.
crypto keyring KEY1 vrf INTERNET pre-shared-key address 192.0.2.101 key TEST.KEY
Now we create and ISAKMP profile, which is really the blood and guts that make all this work. An ISAKMP profile references some of the important pieces of the tunnel – the IVRF in which to place the traffic, the keyring to use, and tunnel endpoint, and the FVRF where the tunnel terminates.
crypto isakmp profile CUSTOMER1-PROFILE vrf CUSTOMER1 keyring KEY1 match identity address 192.0.2.101 255.255.255.255 INTERNET
We’ll then create the ACL for interesting traffic. I’ll save some trees and not go through that since this should be pretty easy by now.
Now we can create the crypto map. This will be just like any other crypto map you’ve ever made with one exception; this is where you include that nifty ISAKMP profile we just made.
crypto map CM 100 ipsec-isakmp set peer 192.0.2.101 set transform-set TS set isakmp-profile CUSTOMER1-PROFILE match address CUSTOMER1-TRAFFIC
Just like in other cases, we need to add a static route to make sure the router sends the packets destined for the remote end of the tunnel out the right interface. Since the FVPN is INTERNET, we’ll add static routes for that VRF. We’ll do the same for the tunnel endpoint just in case the default routes doesn’t go the right way.
ip route vrf INTERNET 192.0.2.101 255.255.255.0 192.0.2.2 ip route vrf INTERNET 10.0.0.0 255.255.255.0 192.0.2.2
Now the tunnel should be up, right? Probably not. If you take a close look, you’ll see that the FVRF has the route to the remote network, but the IVRF – the one that will use the tunnel – doesn’t. We’ll need to use MPBGP to leak those routes from one VRF to another. Did I mention that route leaking can get long-winded and that I’m not going to get into it? Yeah…it can get that bad. Just trust me that this works.
What we’re going to do is to start up BGP for both VRFs. At the same time, we’ll redistribute the static routes that we added above from the FVRF into the IVRF. Since we set up our imported and exported route-targets in the VRF definition, the static routes will magically appear in both VRFs.
router bgp 65000 bgp router-id 192.0.2.1 ! address-family ipv4 vrf INTERNET redistribute static exit-address-family ! address-family ipv4 vrf CUSTOMER1 exit-address-family
If we do a show ip route vrf CUSTOMER1, we’ll see the static routes from the INTERNET VRF. They’re real easy to spot. :)
... B 10.0.0.0 [20/0] via 192.0.2.102 (INTERNET), 00:00:05 ... B 192.0.2.1 [20/0] via 192.0.2.102 (INTERNET), 00:00:05 ...
That should do it. Now you should be able to talk from your local network in the CUSTOMER1 VRF and talk through a tunnel that’s established on the INTERNET VRF.
Send any Juniper configs questions my way.
Invisible fences for VLANs
This week we have a guest post from CJ Infantino. He is currently writes on convergingontheedge.com. You can find him hanging out on Google Plus as CJ Infantino or follow him @cjinfantino on twitter.
————————————-
The other day I was adding VLANs to the the allowed list on the core routers at work. It was then a question came to mind, “Does the VLAN allowed list filter ingress or egress traffic?”.
Now, because all good engineers would configure the allowed list on both ends – as Aaron would say – in the grand scheme of things this really doesn’t matter, but being the inquisitive guy that I am, I wanted to know.
So I searched, and searched and google’d and could not find the answer. At that point there was only one thing left to do – lab it up!
Frame Relay Notes – DE, FECN, and BECN
- All are part of the frame relay congestion management suite.
- Frame relay switches monitor links for CIR or oversubscription congestion on links.
- If the VC has a CIR of 256k, the switch knows there is congestion if the customer is sending more than 256k down that VC.
- Discard Eligible
-
- Flag in the LAPF header
- Marks a frame as eligible to be dropped in case of congestion
- Marked via the MQC
- Forward Explicit Congestion Notification
- Flag in the LAPF header
- Set by the switch when the frame is about to enter a link with congestion on a VC
- Congestion in one direction
- FECNs are set when the frame is going into the congestion.
- Receiving router can see that there was congestion on the way.
- FECNs can be used to activate adaptive shaping via FRTS.
- Plain English: If Router B receives a frame with the FECN flag set, that means that there is congestion on the path from Router A to this Router B, and that Router B should expect delays.
- Backward Explicit Congestion Notification
- Flag in the LAPF header
- Set by the switch when a frame has just left the link with congestion
- Congestion is the opposite direction.
- BECNs are set when the frame has just left a link that has congestion on it.
- Notifies the original sending router that there is congestion along that VC.
- Plain English: If Router A receives a frame with the BECN flag set, that means that there is congestion from Router A towards Router B and that the sending host should calm down a little bit.
http://www.sinclair.org.au/keith/networking/frame_relay.html
–
Corrections requested.
Frame Relay Notes – LMI, Headers, and Encapsulation
- Manages link between the router and frame relay switch
- Routers send Status Enquiry to the switch
- The switch responds with a Status message informing the router of the DLCIs available
- Serves as a keepalive
- Default keepalive is 10 seconds, 3 misses is failed
- Three types
- cisco <- default
- ansi (Annex D)
- q933a
R1(config)#interface s1/0 R1(config-if)#frame-relay lmi-type ansi
- Link Access Procedure for Frame-mode Bearer Services (LAPF) is the first header
- Includes DLCI, DE, FECN, BECN
- To be read by the frame relay switch
- Frame relay encapsulation header is next
- To be read by the router on the other end of the VC
- Two types
- cisco : proprietary <- default
- ietf : IETF RFC 2427
R1(config)#interface s1/0 R1(config-if)#frame-relay encapsulation ietf <- for all DLCIs - or - R1(config-if)#frame-relay interface-dlci 100 ietf <- for specific DLCIs - or - R1(config-if)#frame-relay map ip 10.0.0.1 ietf <- for specific DLCis
PPP Notes – LFI
- Link Fragmentation and Interleaving
- A QoS tool to prevent smaller, higher-priority packets from waiting on larger packets to transmit
- For example, VoIP packets and FTP packets
- Fragments the larger packets and interleaves them with the smaller packets
- Only available in PPP with Multilink
- Can be a multilink bundle with a single link in it
- Common to use with LLQ to interleave the delay-sensitive packets
- fragment-delay allows you to change the fragment size
- In milliseconds
- size = fragment-delay * bandwidth of interface
R1(config)#interface Multilink 1 R1(config-if)#bandwidth 512 R1(config-if)#ppp multilink interleave R1(config-if)#ppp multilink delay 10
–
Corrections, please.
Redistribution Notes – AD Manipulation
- Manipulating administrative distance (AD) is another way to help with a mutual redistribution scenario.
- EIGRPs has different ADs for internal and external (redistributed) routes
- OSPF and RIP have the same AD no matter where the route orginated.
- This means that routes redistributed into OSPF may be used instead of a local RIP route.
- AD 110 (OSPF) beats 120 (RIP) every time.
- The distance subcommand allows you to change the AD on specific routes from specific neighbors.
- This example changes the AD of the route to 10.0.0.0/16 advertised from 1.1.1.1 to 121.
- This will make this router prefer a RIP route to the same destination.
ip access-list standard RIP-ROUTES permit 10.0.0.0 0.255.255.0 ! router ospf 1 distance 121 1.1.1.1 0.0.0.0 RIP-ROUTES
–
Corrections are encouraged.
Redistribution Notes – Tagging
- Tagging provides a way to mark common or similar routes to manipulate later.
- In redistribution scenarios with mutual redistribution on two different routers, any routes that gets redistributed from one route process to another are tagged.
- When the other router sees those tags on the route, that route to keep from adding non-optimal routes to its routing table.
- Tags can also be used to do other manipulation such as setting higher metrics or changing ADs.
OSPF
R102#show run ... router ospf 1 log-adjacency-changes redistribute connected subnets route-map SETTAG network 192.0.2.0 0.0.0.255 area 0 ! route-map SETTAG permit 100 set tag 55555 ... R101#sh ip route 10.0.0.2 Routing entry for 10.0.0.0/24 Known via "ospf 1", distance 110, metric 20 Tag 55555, type extern 2, forward metric 10 Last update from 192.0.2.102 on Ethernet0/0, 00:00:13 ago Routing Descriptor Blocks: * 192.0.2.102, from 192.0.2.102, 00:00:13 ago, via Ethernet0/0 Route metric is 20, traffic share count is 1 Route tag 55555
EIGRP
R102#sh run
...
router eigrp 1
network 192.0.2.0
redistribute connected route-map SETTAG
no auto-summary
!
route-map SETTAG permit 100
set tag 55555
...
R101#sh ip route 10.0.0.2
Routing entry for 10.0.0.0/24
Known via "eigrp 1", distance 170, metric 409600
Tag 55555, type external
Redistributing via eigrp 1
Last update from 192.0.2.102 on Ethernet0/0, 00:00:14 ago
Routing Descriptor Blocks:
* 192.0.2.102, from 192.0.2.102, 00:00:14 ago, via Ethernet0/0
Route metric is 409600, traffic share count is 1
Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
Route tag 55555
–
Corrections are encouraged.