Tag Archives: Cisco

Working configuration for Telecom Italia 4 Mbps SHDSL 4-wire bonding

Posted on by Pier Carlo Chiodi
2 Comments

Some time ago I had to setup a router for a customer who required a 4 Mbps link. The chosen solution was based on a 4 Mbps SHDSL with four-wire bonding, which has a better throutput than a 4 Mbps with ATM IMA. These days a friend needed a help on setting this solution up again, so I would like to share it on my blog.

Technology

The DSLAM obtains the 4 Mbps link by multiplexing 2 links at 2 Mbps each, with no overhead (unlike IMA) and a gross max data rate of 4608 Kbps; this is what we can read in the Telecom Italia Bitstream Reference Offer:

accesso simmetrico “4 Mbit/s bonding” senza modem, con 2 coppie in rame, ognuna delle quali è terminata su una borchia RJ11, e protocollo ATM in tecnologia SHDSL ITU-T G.991.2 Annex B in modalità four-wire (bonding fisico)   “4 Mbps bonding” symmetric access without modem, with 2 copper pairs, each on a RJ11 wall jack, ATM protocol on SHDSL ITU-T G.991.2 Annex B technology, four-wire (physical bonding) mode

(my English is quite poor, maybe you can have more luck with the Google Translator)

Hardware Platform and IOS version

The hardware platform I used for the solution is based on a 2651XM router with WIC-1SHDSL-V2 card; V2 is the first release of the card supporting the 4-wire mode. For what concerns the IOS, be sure to use a release with support for the “standard” option on the “line-mode 4-wire standard” command; it has been introduced in the 12.4(2)XA release and it is needed to enable handshaking only on the master wire pair.

Cabling

A Y-cable is needed to connect the two RJ11 wall jacks to the RJ11 port on the controller; to build the cable you can use the following diagrams I found on the G.SHDSL Cisco High-Speed WAN Interface Cards Q&A page:

SHDSL 4-wire bonding - 2-pair G.SHDSL HWIC Connector Front View Pinout

SHDSL 4-wire bonding - Standard RJ-11 Connector to Two Standard RJ-11 Connectors

Basic configuration

This is the basic configuration; in the example the point-to-point interface is on X.Y.Z.0/30 subnet, with .2 assigned to our router:
 

controller DSL 0/0
 mode atm
 line-term cpe
 line-mode 4-wire standard
 dsl-mode shdsl symmetric annex B
 line-rate 4608
!
interface ATM0/0
 no ip address
 no atm ilmi-keepalive
!
interface ATM0/0.1 point-to-point
 ip address X.Y.Z.2 255.255.255.252
 pvc 12/35
  protocol ip X.Y.Z.1
  oam-pvc manage
  oam retry 3 5 1
  encapsulation aal5snap

References

Cisco.com: Symmetrical High-Bit Rate DSL Interface Card for Cisco Routers

Cisco.com: ATM Mode for Two-Wire or Four-Wire SHDSL

Cisco.com: G.SHDSL Cisco High-Speed WAN Interface Cards Q&A

Telecom Italia: Telecom Italia WholeSale

Categories: Networking | Tags: , , , ,

Cisco Product Quick Reference Guide, September 2009 edition is out

Posted on by Pier Carlo Chiodi
No Comments

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

Categories: Networking | Tags: ,

GNS3 Lab: Any Transport over MPLS (AToM) basic configuration for Ethernet 802.1q and Frame-relay

Posted on by Pier Carlo Chiodi
10 Comments

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

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

PE routers

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.

Port mode Ethernet over MPLS (EoMPLS)

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, DLCI-to-DLCI mode

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.

Packet captures

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!

Conclusion and download

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.

References

Cisco.com: MPLS AToM Technical Overview

Cisco.com: Any Transport over MPLS

Categories: Networking, Networking Labs | Tags: , , , , , , , , ,

Automatically filtering bogons with BGP and Team Cymru Bogon Route Server Project

Posted on by Pier Carlo Chiodi
No Comments

ThiefWhat 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!)

Read more …

Categories: Networking, Security | Tags: , , , , , , , , ,

Cisco IOS configuration management using SCP and pscp

Posted on by Pier Carlo Chiodi
7 Comments

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:MyConfigsR1.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!

References

Cisco.com: Cisco Guide to Harden Cisco IOS Devices

Cisco.com: Cisco Secure Copy (SCP) Feature Guide – 12.2T

PuTTY: PuTTY: A Free Telnet/SSH Client

Categories: Networking | Tags: , , , ,