From: Question 56 Subject: What does Frame-relay LMI and Encapsulation really do/mean? I think there is some confusion here about frame relay "encapsulation" and frame relay "lmi" (heartbeat/keepalives). Frame relay encapsulation is indeed significant end-to-end through the "cloud" between communicating DTE (router) equipment. Cisco encapsulation inserts an ethernet "type field" immediately after the 2 byte frame header which contains the DLCI, FECN, BECN, and DE fields. IETF (RFC 1490) encapsulation does not use ethernet type fields to identify the payload of the frame. Instead, IETF calls for the use of NLPID codes (Network Layer Protocol Identifiers) which are common in the OSI environment. NLPIDs are to be used when the payload has an NLPID assigned to it.(like IP) The NLPID (CC, in the case of IP) will follow an Unnumbered Information UI control field, 03. If the payload does not have an NLPID assigned to it, (like IPX) then IETF suggests that an OUI field (organizationally unique identifier) followed by an ethernet type code (8137 for example, if IPX) will be used. Much like an 802.3 frame with SNAP, the type code of 8137 will be offset further into the frame, and not found immediately after the 2 byte frame header. This encapsulation must be understood by the communicating routers at either edge of the 'cloud.' The cloud itself does not care what type of "encapsulation" is being used. It is strictly a DTE-DTE issue. LMI is a link intergrity and PVC status verification protocol that IS locally significant between the router and the network interface. This protocol comes in 3 flavors: the 'original' Stratacom' (aka cisco) version, ANSI's T1.617 Annex D, and CCITT/ITU Q.933 Annex A. These protocols are often collectively referred to as "LMI." It is possible to run one version of LMI on the East User-Network Interface (UNI) and another version on the West UNI, as these protocols simply identify the status of the UNI link and the PVCs found on that link. Encapsulation, however, must match between the DTEs. It is interesting to note, however, that Cisco routers are smart enough to interpret the 'encapsulation' type being used on incoming frames. If both DTEs are Cisco routers, one router 'can' use Cisco encapsulation while the other router uses "IETF." The ability to communicate with Cisco routers using different encapsulation schemes gives the "appearance" that the encapsulation is locally significant. In fact, this (cisco) ability to communicate is made possible by the smarts cisco builds into its implementation. When any other vendor's DTE is involved, communications will fail if the "encapsulation" on both DTEs is not identical. Even if one of the routers is a cisco. (Unless, of course, the other vendor saw fit to build in the smarts that cisco has done. But I am not aware of any vendor that has this capability other than cisco ) Hex protocol traces are available if any one would like to see ****************************************************************** ******** From: Question 58 Subject: How do I make a T1 Cross-over cable? For *T1* I've used the following pinouts for crossovers: T1/E1 crossover (for PRI and CAS back-to-back connection): RJ-45 RJ-45 1 4 2 5 4 1 5 2 RJ-45 DB-15 1 1 2 9 4 3 5 11 DB-15 DB-15 1 3 3 1 9 11 11 9 For E1 (assuming RJ-48 aka RJ-45), the pinouts would be the same as for T1, except that I guess you need to have pins 3 and 6 (shield/ground) connected. I don't suppose I should be pointing people to Juniper's web site, but anyway http://www.juniper.net/techpubs/hardware/m160/m160- picinstall/html/pinout5.html ****************************************************************** ******** From: Question 59 Subject: Can I use a router to simulate BRI switch? In current IOS (12.1(3)T and above, I think), you can configure PRIs back-to-back between routers: configure one side to be network side (isdn protocol-emulate network) and the other to be user side (default; isdn protocol-emulate user). The supported switchtypes are primary-net5 and primary-ni. As the original posting had alluded, we have SOME support for network-side BRI - but this is only on certain VIC cards due to hardware restrictions - http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft /121limit/121x/121xi/121xi_3/dt_brint.htm ****************************************************************** ******** From: Question 60 Subject: How do I use Policy Based Routing? Keep in mind that Policy routing works on the INBOUND interface. If you think about it, it makes sense. The decision to hand off the packet has to be made as it's coming into the router and not on the egress interface. Determine who's eligible to be policy routed access-list 1 permit 10.1.1.0 0.0.0.255 Figure out where you want to send the pkts based on the source IP route-map RouteMeBaby permit 10 To whom shoud this policy apply to? match ip address 1 Where should you redirect it to? Should use both. If one is omitted, the value will be retrived from the routing table - which may or may not be what you wanted set ip next-hop ROUTER_2's_SERIAL_IP set interface s0 interface E0 ip addr blah blah blah ip policy route-map RouteMeBaby If your IOS supports it, enable fast switching for PBR ip route-cache policy *IF* fast switching is supported (may be 11.3 an up or it could be 12.0 and up do a sho ip cache policy if not, do a sho ip policy ****************************************************************** ******** From: Question 61 Subject: How do I setup a VPN tunnel using pre-shared keys? Dror-John is right. There is a LOT to know about when you get into encryption, and like any other branch of this industry knowing the hows & whys will help your configs and troubleshooting enormously. The CCO IPSec Product Support page has a wealth of useful info and examples. www.cisco.com/pcgi- bin/Support/PSP/psp_view.pl?p=Internetworking:IPSec RFCs 2401-2412 are not too taxing either. I've added below a very basic example using pre-shared keys, DES encryption and SHA-1 hashing algorithm. Site 1 is 10.0.1.0/24, site 2 10.0.2.0/24 and the serial i/fs 10.0.4.0/30 (& assumes you have sub-i/fs). Names and things in capitals. Router1(config)# crypto isakmp policy 1 Define your ISAKMP policy settings group 2 'group' defines the modulus for Diffie-Hellman calculation. Default is group 1, less CPU work, but less secure. authentication pre-share crypto isakmp key SHARED_KEY_HERE address 10.0.4.2 Your shared key, and what peer i/f it's used for. crypto ipsec transform-set TS1 ah-sha-hmac esp-des Define what happens to the traffic. AH & ESP are two IPSec protocols. crypto map TO_SITE_2 10 ipsec-isakmp Define crypto-map set peer 10.0.4.2 The other side set transform-set TS1 Which transform-set to use match address 150 What traffic to include interface Serial1/0.0 ip address 10.0.4.1 255.255.255.252 crypto map TO_SITE_2 Apply the crypto-map to the i/f access-list 150 permit ip 10.0.1.0 0.0.0.255 any Include traffic coming from here. I've said anything going out, for there may be places beyond Site 2, but Cisco says this can cause problems for multicast traffic. This also assumes no traffic will be going to Site 2 from somewhere else _through_ Site 1. Perhaps best to err on the more specific side. However it is a good idea to not include your serial i/fs, so you can still get at the far router if there's a problem. Router2(config)# crypto isakmp policy 1 group 2 authentication pre-share crypto isakmp key SHARED_KEY_HERE address 10.0.4.1 crypto ipsec transform-set TS1 ah-sha-hmac esp-des crypto map TO_SITE_1 10 ipsec-isakmp set peer 10.0.4.1 set transform-set TS1 match address 150 interface Serial1/0.0 ip address 10.0.4.2 255.255.255.252 crypto map TO_SITE_1 access-list 150 permit ip 10.0.2.0 0.0.0.255 any ****************************************************************** ******** From: Question 62 Subject: Why does one packet always get dropped on the last hop of traceroute? And the winner is Max. Inspired by (I think) sec. 4.3.2.8 in RFC-1812, we rate- limit our ICMP message generation to 1/sec/destination. This can be adjusted by the "ip icmp rate-limit unreachable" command. More interesting than simply causing an oddity for traceroute, ICMP rate-limiting can cause intermittent PMTUD blackholes (or I should say perhaps "PMTUD brownholes".) If you're doing PMTUD (as alas anyone running Windows defaults to), then you might want to ease the rate limit on DF unreachables. ****************************************************************** ******** From: Question 63 Subject: How to setup NATing based on outgoing interface to two different ISPs. > ISP1 CableModem > \ / > \ / > > Cisco 2621 > | > | | > Firewall Mail Server > | > > Company LAN > > We just installed a T1 to the Internet to co-exist with our Cablemodem. I > am looking at ways to implement this. We currently have a Cisco 2621 with > the T1 connection and a Linux Box Masqing cablemodem Internet access now. > My question is, what would be the best way to implement this? > > I proposed we connect the Cablemodem into the 2621 (FEthernet interface) > next to the T1 connection (separate ISP's btw) and NAT. That will work. But you need to use route-maps to match the outgoing interface (or next-hop) when you define your NAT pool. In a nutshell . after the 2 byte frame header which contains the DLCI, FECN, BECN, and DE fields. IETF (RFC 1 490) encapsulation does not use ethernet type fields to identify the payload of the frame. Instead,