Just another Cisco blog
Tutorials
MPLS and BGP Lab Guide, Part 1
Dec 4th
This is the first post in the series, the goal of the series is to provide a guide for the MPLS and BGP Lab I posted awhile back. The labs consists of MPLS VPNs and BGP along with some OSPF, NAT, IPSEC and GRE exposure. I will be posting the files needed for this lab at the bottom. Here’s the topology and the requirements:
(click image for fullsize)
Requirements:
Internet
* The two Internet routers should serve as transit ASes. No other routers should permit transit traffic.
* Internet sites (modeled by loopbacks) should be accessible by all lan IPs.
DMVPN Tutorial
Dec 2nd
I’ve been interested in Dynamic Multipoint VPN (DMVPN) for quite awhile, I decided to lab it a few months ago, but never posted about it. We use EasyVPN at my company, which functions similarly in that it doesn’t require static IPs on the spoke devices, which means there is less config per new deployment. What makes DMVPN so much better (IMO) than EasyVPN is it’s ability to make dynamic spoke-to-spoke tunnels. This is very, very cool. One drawback, which affects companies like mine, is that DMVPN is not supported on firewalls, which is what most of our VPN deployments use. Here’s the topology:
Let’s get to the config:
R2 (hub router)
hostname R2 ! interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Loopback25 ip address 10.1.25.1 255.255.255.255 ! interface FastEthernet1/0 ip address 10.1.2.2 255.255.255.252 ! interface Tunnel200 ip address 192.168.5.2 255.255.255.0 no ip redirects ip nhrp map multicast dynamic ip nhrp network-id 200 tunnel source 10.1.25.1 tunnel mode gre multipoint |
There aren’t any “dmvpn” configuration commands (that I know of), as you can see, it’s all done with NHRP. NHRP (Next Hop Resolution Protocol) is what makes all of this work.
R1 interface Tunnel200 ip address 192.168.5.1 255.255.255.0 no ip redirects ip nhrp map multicast 10.1.25.1 ip nhrp map 192.168.5.2 10.1.25.1 ip nhrp network-id 200 ip nhrp nhs 192.168.5.2 ip nhrp cache non-authoritative tunnel source 10.1.1.2 tunnel mode gre multipoint ! interface FastEthernet1/0 ip address 10.1.1.2 255.255.255.252 R3 interface Tunnel200 ip address 192.168.5.3 255.255.255.0 no ip redirects ip nhrp map multicast 10.1.25.1 ip nhrp map 192.168.5.2 10.1.25.1 ip nhrp network-id 200 ip nhrp nhs 192.168.5.2 ip nhrp cache non-authoritative tunnel source 10.1.3.2 tunnel mode gre multipoint ! interface FastEthernet1/0 ip address 10.1.3.2 255.255.255.252 R4 interface Tunnel200 ip address 192.168.5.4 255.255.255.0 no ip redirects ip nhrp map multicast 10.1.25.1 ip nhrp map 192.168.5.2 10.1.25.1 ip nhrp network-id 200 ip nhrp nhs 192.168.5.2 ip nhrp cache non-authoritative tunnel source 10.1.4.2 tunnel mode gre multipoint ! interface FastEthernet1/0 ip address 10.1.4.2 255.255.255.252 |
Show Run Variations
Nov 28th
A recent thread on TechExams gave me the idea for a post on all the variations of the “show run” command. In this article I’ll go through the variations that I use the most, and some others that I don’t use much, but are pretty helpful.
Let’s take a look:
First we’ll look at all the options provided by IOS help:
EDGE#sh run ? all Configuration with defaults brief configuration without certificate data class-map Show class-map information control-plane Show Control-Plane information flow Global Flow configuration subcommands full full configuration interface Show interface configuration linenum Display line numbers in output map-class Show map class information policy-map Show policy-map information ssid Show Dot11 SSID information view View options vlan Show L2 VLAN information vrf Show VRF aware configuration | Output modifiers |
I’m sure everyone reading this has used good old “sh run” many times. What about the other options? I use “sh run interface” quite a bit:
EDGE#sh run int fa0/0 ... interface FastEthernet0/0 description OUTSIDE ip address xx.xx.xx.xx 255.255.255.248 ip access-group OUTSIDE_IN in no ip redirects no ip unreachables no ip proxy-arp ip accounting access-violations ip nbar protocol-discovery ip nat outside ip virtual-reassembly load-interval 30 duplex auto speed auto no cdp enable service-policy input QoS_IN service-policy output SHAPER end |
That and “sh run | section” are probably the variations I use most:
EDGE#sh run | sec ephone-dn ephone-dn 1 dual-line number 5001 no-reg primary label Colby name Colby ephone-dn 3 number 5003 no-reg primary label Laptop name Colby-Laptop ephone-dn 4 number 5004 no-reg primary name Wireless ephone-dn 5 number 5005 no-reg primary ephone-dn 6 number 5006 no-reg primary name Katie ephone-dn 11 dual-line number 555-555-5555 label 555-555-5555 name Colby |
That one is perfect for times when you are looking for specific parts of the config, without having to wade through everything.
A new one I just learned from Networking-Forum:
EDGE#sh run Building configuration... ! version 12.4 service timestamps debug datetime msec service timestamps log datetime msec service password-encryption ! /ospf <--- I typed this filtering... router ospf 200 router-id 192.168.254.254 log-adjacency-changes network 192.168.5.0 0.0.0.255 area 1 network 192.168.13.0 0.0.0.3 area 0 network 192.168.254.254 0.0.0.0 area 0 |
Policy-Based Routing Tutorial
Nov 18th
A friend asked me how to implement Policy-Based Routing (PBR) yesterday, after explaining it to him I thought it’d be nice to write a quick tutorial on here. PBR allows you to change a packet’s path based on different criteria. In this post I will use my friend’s scenario. We have a business with two internet connections, the powers that be have decided to use ISP B for all outbound SMTP traffic. Here’s our topology:
Let’s go through the config:
R1
hostname R1 ! ip access-list ext MATCH_SMTP 10 permit tcp 192.168.1.0 0.0.0.255 any eq 25 20 deny ip any any ! route-map SMTP_ISPB permit 10 match ip address MATCH_SMTP set ip next-hop 67.92.18.1 ! interface fa0/1 ip add 192.168.1.1 255.255.255.0 ip policy route-map SMTP_ISPB |
First we create our ACL that matches outgoing SMTP traffic, then we match the ACL in a route-map. After we match the traffic, we enter our action statement, “set ip next hop”. This route-map changes the next hope of all outgoing SMTP traffic. Finally we configure it on the LAN interface.
BGP Backdoor Lab
Nov 12th
In this article we’ll be going over the BGP Backdoor feature. This is used in cases where two systems are connected via an IGP, but also receiving routes to the same system through BGP. I stumbled across this feature while checking out one of the labs on Darren’s Blog. The only way I could think of to complete one of his criteria was changing the Administrative Distance of either BGP or the IGP. That is essentially what this feature does, but on a route-by-route basis instead of changing the AD of an entire protocol. I asked Darren if that was the only solution and he pointed me to “BGP Backdoor”. As usual, I will be including my Dynagen/GNS3 .net file at the end of this post. Here is our topology:
Let’s go through the config:
R1
hostname R1 ! interface Serial0/0 ip address 10.1.1.1 255.255.255.0 ! interface Serial0/1 ip address 10.1.3.1 255.255.255.0 ! router bgp 65000 no synchronization bgp log-neighbor-changes neighbor 10.1.1.2 remote-as 65525 neighbor 10.1.3.2 remote-as 65535 no auto-summary |
Recent Comments