Posted by pierky on December 15, 2009
As the title says, the Cisco Product Quick Reference Guide new edition is out and publicly available on the Document Center.
For those not familiar with the CPQRG, it’s a very useful, portable summary of Cisco products and services.
You can find it here: http://www.cisco.com/en/US/prod/qrg/index.html
Posted in Networking | Tagged: Cisco, LinkedIn | Leave a Comment »
Posted by pierky on December 7, 2009
AToM stands for Any Transport over MPLS, a quite reassuring technology which, provided you have a MPLS enabled network and some good gears, let you set up L2 circuits across your IP backbone.
This lab offers a very simple topology with 2 AToM links; an ethernet with an 802.1q trunk and a frame-relay link.
Core (P) routers configuration is pretty simple; we only enable MPLS switching on interfaces toward PE routers and setup LDP for labels exchange. A good core doesn’t care about what kind of traffic it switches!
P1:
mpls label protocol ldp ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface FastEthernet0/0 description PE1 facing interface mpls ip ! interface FastEthernet1/0 description P2 facing interface mpls ip ! mpls ldp router-id Loopback0 force
The hard work is done on PE routers. PE routers face CE routers, which they receive L2 traffic from, and network core P routers, which they have to send MPLS encapsulated traffic to.
In order to build up a L2 circuit, PE routers have to setup a pseudowire connection between them, so they know how to switch traffic. Each pseudowire uses a virtual-circuit ID (VC ID), which is locally significant on each PE pair and is used to identify the pseudowire itself and to bind it to a specific MPLS label.
First off, they must be MPLS aware:
PE2
mpls label protocol ldp ! interface Loopback0 ip address 1.1.2.2 255.255.255.255 ! interface FastEthernet0/1 description P2 facing interface mpls ip ! mpls ldp router-id Loopback0
Now, we have to set up pseudowires between PE and L2 connections with CEs.
Let’s start with the Ethernet 802.1q trunk.
In port mode EoMPLS every frame received on a PE interface is forwarded to the other PE almost unchanged (just preamble and FCS are removed).
Basic configuration is very simple:
PE2
interface FastEthernet0/0 description CE_Switch2 facing interface no ip address duplex auto speed auto xconnect 1.1.2.1 10 encapsulation mpls
The xconnect command does all the work! This command tells the PE router to encapsulate every frame in a MPLS packet and to forward it to the peer 1.1.2.1 using VC ID 10.
It also allow Label Distribution Protocol (LDP) to exchange informations about the pseudowire circuit between PEs (VC ID / label mapping, VC type, MTU).
Once we have applied this configuration to both PE routers (on PE1 we have to change the xconnect peer address!), we can verify if LDP did its work and if pseudowire is up:
PE2#show mpls l2transport vc 10 detail
Local interface: Fa0/0 up, line protocol up, Ethernet up
Destination address: 1.1.2.1, VC ID: 10, VC status: up
Output interface: Fa0/1, imposed label stack {18 16}
Preferred path: not configured
Default path: active
Next hop: 172.16.2.0
Create time: 01:16:07, last status change time: 01:15:44
Signaling protocol: LDP, peer 1.1.2.1:0 up
MPLS VC labels: local 16, remote 16
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
[cut]
Now, setup and test VLAN connectivity on customer side:
Net1_H1#sh run int fa0/0 | beg interface interface FastEthernet0/0 ip address 192.168.1.1 255.255.255.0 duplex auto speed auto end Net1_H2#sh run int fa0/0 | beg interface interface FastEthernet0/0 ip address 192.168.1.2 255.255.255.0 duplex auto speed auto end Net1_H1#ping 192.168.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 148/168/192 ms
Frame-relay over MPLS requires a few more lines of configuration, but the pseudowire setup is the same as EoMPLS.
We have to enable frame-relay switching on the PE router, configure the Serial interface as DCE and setup the switching path for the DLCI:
PE2
frame-relay switching ! interface Serial1/0 no ip address encapsulation frame-relay IETF frame-relay intf-type dce ! connect FR2-FR1 Serial1/0 201 l2transport xconnect 1.1.2.1 20 encapsulation mpls
PE1
frame-relay switching ! interface Serial1/0 no ip address encapsulation frame-relay IETF frame-relay intf-type dce ! connect FR1-FR2 Serial1/0 102 l2transport xconnect 1.1.2.2 20 encapsulation mpls
Let’s verify everything is ok:
PE2#show mpls l2transport vc 20 Local intf Local circuit Dest address VC ID Status ------------- -------------------------- --------------- ---------- ---------- Se1/0 FR DLCI 201 1.1.2.1 20 UP
With this configuration we have DLCI 102 for FR1-to-FR2 traffic, and DLCI 201 for FR2-to-FR1 traffic.
Customer side configuration:
FR1
interface Serial0/0 no ip address encapsulation frame-relay IETF ! interface Serial0/0.1 point-to-point ip address 172.16.0.1 255.255.255.252 frame-relay interface-dlci 102
Similar configuration on FR2:
interface Serial0/0.1 point-to-point ip address 172.16.0.2 255.255.255.252 frame-relay interface-dlci 201
Some tests…
FR1#show frame-relay lmi
LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 615 Num Status msgs Rcvd 573
Num Update Status Rcvd 0 Num Status Timeouts 42
Last Full Status Req 00:00:24 Last Full Status Rcvd 00:00:24
FR1#
FR1#show frame-relay pvc
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1
input pkts 115 output pkts 120 in bytes 32266
out bytes 33844 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 100 out bcast bytes 31764
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 01:43:39, last time pvc status changed 01:10:26
FR1#
FR1#ping 172.16.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 164/185/220 ms
Please note how the subnet 172.16.0.0/32 on the FR routers does not conflict with 172.16.0.0/31 between P routers; it’s on a totally different L3 domain and it is not routed by the network, but transparently encapsulated in L2 over MPLS packets.
You can find some nice packet captures about this lab at PacketLife.net Captures section, under the MPLS category; they have been taken on P1-P2 link, with inner (pseudowire) and outer MPLS label on top of every packet. They are “LDP_Ethernet_FrameRelay”, which shows how LDP setup the pseudowire circuit, “EoMPLS_802.1q” and “Frame-Relay over MPLS”, which show an ICMP ping encapsulated in Ethernet and Frame-relay respectively.
Anyway, if you don’t know PacketLike.net you must take a tour of that great website, really worth it!
This post only shows a little basic configuration of some AToM solutions; there are many more capabilities than which I wrote on this blog. A good starting point is to read documents you can find using links below.
If you want to download this GNS3/Dynamips lab, you can find it here.
Cisco.com: MPLS AToM Technical Overview
Cisco.com: Any Transport over MPLS
Posted in Networking, Networking Labs | Tagged: 802 DOT1Q, 802.1q, AToM, Cisco, EoMPLS, Frame-Relay, GNS, GNS3, LinkedIn, MPLS | 2 Comments »
Posted by pierky on October 28, 2009
What do you do if someone knocks at your door, you see him through the peephole, and you notice he has a black cowl, a crowbar and a big bag? I’m quite sure: you do not open that door! Why? Because, sometimes, the gown does make the friar! And, actually, he’s really not a friar!
Same thing should happen in a network! If you know a packet is a bad packet, why should you let it go through?
In this (stupid) example bad packets are those coming from or going toward bogon IP addresses, that is, addresses picked up from unallocated or private (so, not routable) address spaces. As you know, there are many subnets used only for private addressing (RFC 1918), other are reserved (RFC 3330), and few subnets are still not allocated by IANA… so, if your router is sending or receiving a packet to/from one of these addresses, there is something you should be concerned about (of course, some restrictions may apply!)
In order to identify and catch bogon packets we need to know which subnets have to be marked as bogon.
One way to achieve this goal is to deploy static ACLs or route filters on every router we want to secure… a quite boring job on its own! But, what happens when IANA allocate one of the previously unallocated (so, bogon) subnets? Well, we have to change those ACLs on every router! This is a very boring job! Someone at RIPE knows that well!
Do you really want this?
Fortunately, we can use a great utility by Team Cymru: Bogon Route Server Project.
For the sake of our sanity, Team Cymru deployed some route servers running BGP which announce bogon prefixes over eBGP peering sessions. Once we have a BGP-aware box, we can get those prefixes and do what we want of them.
Here, I’ll show how to automatically handle bogon prefixes using a Linux box running Quagga, a routing software suite providing implementation of BGP.
From our central Quagga box we can distribute those prefixes to our routers, or to customers CPEs, and here we can filter traffic on the basis of source or destination addresses.
For example, we can avoid to route packets with a bogon destination address, simply by adding a route toward bogon prefixes with a null-pointing next-hop; it’s a kind of blackhole filtering:
ip route 192.0.2.1 255.255.255.255 Null0 ip route 1.0.0.0 255.0.0.0 192.0.2.1
With Cymru Bogon Route Server Project we can do this job in a fully automatic and central way.
Of course, we can also drop incoming packets presenting bogon source IP addresses; we can accomplish this using uRPF in a kind of source-based black hole filtering:
interface Serial1/0 ip verify unicast source reachable-via any
Anyway, you, and only you know what’s better for your network!
Now, I would like to show you how to setup a Linux box running Quagga, with a peer session with Cymru routers, and how to use it to distribute bogon prefixes to our routers.
At first, we have to ask Team Cymru to setup a BGP session with our Quagga box: to do so we have to contact them on the basis of what we can find on their website. We have to tell them our AS number, our peering IP addresses and optional MD5 passwords and GPG/PGP public key.
You don’t need to have a public AS number, you can also peer with them using a private AS number.
Once we have installed Quagga and received Cymru details, we just have to edit the bgpd.conf file and add a few lines.
Quagga bgpd.conf:
router bgp YOUR_AS_NUMBER bgp router-id YOUR_ROUTER_ID neighbor cymru-bogon peer-group neighbor cymru-bogon remote-as 65333 neighbor cymru-bogon ebgp-multihop neighbor cymru-bogon prefix-list cymru-out out neighbor cymru-bogon route-map CYMRUBOGONS in neighbor cymru-bogon maximum-prefix 100 neighbor CYMRU_PEER_1_IP peer-group cymru-bogon neighbor CYMRU_PEER_2_IP peer-group cymru-bogon ! ip community-list 10 permit 65333:888 ! route-map CYMRUBOGONS permit 10 match community 10 set ip next-hop 192.0.2.1 ! ip prefix-list cymru-out seq 5 deny 0.0.0.0/0 le 32
Prefix-list prevents any update to leave our box toward Cymru routers; route-map allows marked prefixes and set their next-hop to 192.0.2.1, null-pointing route.
Automagically our Quagga box gets bogon prefixes:
QuaggaBox#show ip bgp
BGP table version is 0, local router ID is YOUR_ROUTER_ID
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 1.0.0.0 192.0.2.1 0 0 65333 i
*> 192.0.2.1 0 0 65333 i
* 5.0.0.0 192.0.2.1 0 0 65333 i
*> 192.0.2.1 0 0 65333 i
[cut]
* 192.168.0.0/16 192.0.2.1 0 0 65333 i
*> 192.0.2.1 0 0 65333 i
* 198.18.0.0/15 192.0.2.1 0 0 65333 i
*> 192.0.2.1 0 0 65333 i
* 223.0.0.0/8 192.0.2.1 0 0 65333 i
*> 192.0.2.1 0 0 65333 i
Total number of prefixes 32
Now, setup our Quagga box to bring up peering with your routers; just add few config lines to bgpd.conf:
router bgp YOUR_AS_NUMBER neighbor Clients peer-group neighbor Clients prefix-list DoNotAcceptAnything in neighbor Clients route-map CYMRUBOGONS out neighbor Clients ebgp-multihop neighbor Clients send-community neighbor YOUR_ROUTER1_IP remote-as YOUR_AS_NUMBER neighbor YOUR_ROUTER1_IP peer-group Clients neighbor YOUR_ROUTER2_IP remote-as YOUR_AS_NUMBER neighbor YOUR_ROUTER2_IP peer-group Clients ! ip prefix-list DoNotAcceptAnything seq 5 deny 0.0.0.0/0 le 32
We can deploy iBGP or eBGP configuration on our routers and automatically get bogon prefixes.
This is a sample configuration:
ip route 192.0.2.1 255.255.255.255 Null0 ! ip bgp-community new-format ! router bgp YOUR_AS_NUMBER no synchronization bgp log-neighbor-changes neighbor YOUR_QUAGGA_BOX_IP remote-as YOUR_AS_NUMBER neighbor YOUR_QUAGGA_BOX_IP update-source Loopback0 neighbor YOUR_QUAGGA_BOX_IP prefix-list DoNotAnnounceAnything out neighbor YOUR_QUAGGA_BOX_IP route-map CymruBogons in no auto-summary ! ip community-list standard CymruBogons permit 65333:888 ! ip prefix-list DoNotAnnounceAnything seq 5 deny 0.0.0.0/0 le 32 ! route-map CymruBogons permit 10 match community CymruBogons set ip next-hop 192.0.2.1
And now, let’s verify our job…
Router#show ip bgp
BGP table version is 163, local router ID is X.Y.Z.W
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
*>i1.0.0.0 192.0.2.1 0 100 0 65333 i
*>i5.0.0.0 192.0.2.1 0 100 0 65333 i
[cut]
*>i192.168.0.0/16 192.0.2.1 0 100 0 65333 i
*>i198.18.0.0/15 192.0.2.1 0 100 0 65333 i
*>i223.0.0.0/8 192.0.2.1 0 100 0 65333 i
BGP gets bogon prefixes from our Quagga box; let’s take a look at our routing table, with focus on 192.168.0.0:
Router#show ip route | i 192.168 O IA 192.168.4.0/24 [110/196] via 192.168.254.3, 5d05h, Tunnel1 O IA 192.168.5.0/24 [110/196] via 192.168.254.1, 5d05h, Tunnel0 [cut] O IA 192.168.1.0/24 [110/196] via 192.168.254.1, 5d05h, Tunnel0 B 192.168.0.0/16 [200/0] via 192.0.2.1, 1d01h
Here we have some private prefixes from OSPF, used for branch offices, and they have the right paths; in the last line, the whole 192.168.0.0/16 goes toward the null-pointing route.
Remember: more specific route wins; until we have our private prefixes from OSPF no packets will be filtered out.
Router#sh ip cef 192.168.222.1
192.168.0.0/16, version 411, epoch 0
0 packets, 0 bytes
via 192.0.2.1, 0 dependencies, recursive
next hop 192.0.2.1, Null0 via 192.0.2.1/32
valid null (drop) adjacency
Well done: it’s simple and it works fine! Anyway, remember to take precautions: do no send bogon prefixes to your BGP peers (no-export plus safeguard communities) and keep in mind every network is different from others!
Team Cymru: Bogon Route Server Project
Quagga: Quagga Software Routing Suite
Andree Toonk: Bong Traffic Analysis in 2006
Rob Thomas (on Team Cymru website): 60 Days of Basic Naughtiness, a study conducted in 2001.
Posted in Networking, Security | Tagged: BGP, bgpd, bogon, Cisco, ISP, LinkedIn, Quagga, Team Cymru, uRPF | Leave a Comment »
Posted by pierky on September 28, 2009
SCP is a powerful tool introduced in IOS 12.2(2)T which allows us to securely transfer files to and from our routers. With this feature we can transfer files, images and configurations in an encrypted way, and we can also authenticate accesses on the routers.
It’s easy to deploy, easy to use and Cisco recommends to use it in the Guide to Harden Cisco IOS Devices too: why do not use it?! 
It relays on SSH and AAA, so both features have to be enabled on the device:
Router(config)#hostname R1 R1(config)#crypto key generate rsa general-keys modulus 512 The name for the keys will be: R1.mydomain % The key modulus size is 512 bits % Generating 512 bit RSA keys, keys will be non-exportable...[OK] R1(config)# R1(config)#aaa new-model R1(config)#aaa authentication login default local R1(config)#aaa authorization exec default local
In order to use scp to manage configuration we must have an user account with enough privileges to access it:
R1(config)# R1(config)#username admin privilege 15 secret 0 topsecret
Finally, we can turn the scp server on:
R1(config)#ip scp server enable
On the client side we can use an utility such as pscp, from the PuTTY suite, to interact with our SCP server – the router!
C:\>pscp.exe
PuTTY Secure Copy client
Release 0.59
Usage: pscp [options] [user@]host:source target
pscp [options] source [/source] [user@]host:target
pscp [options] -ls [user@]host:filespec
[cut]
For example, we can download the startup-config and put it on a directory:
C:\>pscp.exe admin@192.168.0.42:nvram:startup-config C:\MyConfigs\R1.cfg admin@192.168.0.42's password: R1.cfg | 0 kB | 0.6 kB/s | ETA: 00:00:00 | 100% C:\>
Using an integrated AAA system, such as a Radius based AAA with IAS and Active Directory as backend, we can also omit the username part and use our own domain password!
Dear TFTP & Co., it’s time for retirement!
Cisco.com: Cisco Guide to Harden Cisco IOS Devices
Posted in Networking | Tagged: Cisco, LinkedIn, pscp, PuTTY, SCP | 2 Comments »
Posted by pierky on September 18, 2009
These days I had to implement centralized terminal authentication on a few Cisco routers using aaa new-model and RADIUS.
The solution in its own was pretty simple: it was based on the usual Microsoft IAS (Internet Authentication Service) which was integrated in an Active Directory domain.
The interesting aspect is that those routers were under different administrative controls, so some users had to be granted access on a part of them and denied on other. Let’s say Group1 had to be enabled on routers RA, RB and RC, while Group2 on routers RD, RE and RF.
In order to achieve this goal we may use a lot of solutions, but most of them are quite unscalable, because we have to map each router to the specific policy.
To obtain a good degree of scalability we may use the radius-server attribute 32 include-in-access-req command. This command tells IOS to append the NAS-Identifier attribute in the RADIUS authentication request message, and let us to set a format for its value:
RA(config)#radius-server attribute 32 include-in-access-req format ? LINE A string where %i = IP address and %h = hostname, %d = domain name
For example, we can prepend the router’s hostname with a “tag” to distinguish the owner group:
Group1 routers:
RA(config)#radius-server attribute 32 include-in-access-req format Group1-%h RB(config)#radius-server attribute 32 include-in-access-req format Group1-%h RC(config)#radius-server attribute 32 include-in-access-req format Group1-%h
Group2 routers:
RD(config)#radius-server attribute 32 include-in-access-req format Group2-%h RE(config)#radius-server attribute 32 include-in-access-req format Group2-%h RF(config)#radius-server attribute 32 include-in-access-req format Group2-%h
Finally we can create two policies in IAS to handle the incoming authentication requests, by filtering them on the basis of NAS-Identifier attribute.
On the NAS-Identifier filter, we can use a star (“*”) to match any character which follows the router’s “tag”. Once we matched the router’s tag, we bind it to the right Active Directory group. Please take a look at the picture for details.
Cisco.com: Cisco IOS Security Command Reference, Release 12.3 T
Cisco.com: Command Lookup Tool
PacketLife.net Blog: Seven free ways to improve your network’s security
Kpjungle’s Weblog: Authentication by Radius on a Cisco device
Posted in Networking | Tagged: AAA, Cisco, LinkedIn, Radius | Leave a Comment »
