Archive for the ‘router’ tag
There are a few ways to leak routes in and out of virtual routers in Junos. On the list is a cool feature called the logical tunnel interface.
So, what am I talking about? One way to separate traffic on a router is to use virtual routers (VRs) so that you wind up with multiple routing tables on the same router. This separate traffic, but you will usually (read: always) have a demand to get traffic from one VR to another. There are a few different way to do that (see rib-group, instance-import, next-table, et al.), but one really cool way to do it is through logical tunnel interfaces.
The logical tunnel (lt-0/0/0) interface is a special little guy that allows you to connect its units to each other. The result is similar to connecting an Ethernet cable from one physical interface to another. With a little configuration, these guys provide a point-to-point interface that you can include in your routing setup. Let’s look at an example.
set interfaces lt-0/0/0 unit 100 encapsulation ethernet set interfaces lt-0/0/0 unit 100 peer-unit 200 set interfaces lt-0/0/0 unit 100 family inet address 192.168.0.100/24 set interfaces lt-0/0/0 unit 200 encapsulation ethernet set interfaces lt-0/0/0 unit 200 peer-unit 100 set interfaces lt-0/0/0 unit 200 family inet address 192.168.0.200/24
The encapsulation lines are pretty straightforward. In this case, I want the link to appear as an Ethernet interface, but you can choose frame-relay, vlan, bridging, and others.
The peer unit lines tell what unit is connected to what other unit. Each lt-0/0/0 unit is a point-to-point link, so you have to tell the router what’s on the other end of the link (sorry…no multiaccess here). In this case, I want unit 100 to connect to unit 200, so I configure both units with the appropriate peer unit.
Of course, we can all figure out that we’re using IPv4 on these new units as well. In this case, I’ve put both interfaces on the 192.168.0.0/24 network (how original!).
Now that we have our interfaces configured, we need to put these interfaces into the correct VR. Don’t forget the security zone, too, if you’re running in flow mode. That’s beyond the scope here, though.
set routing-instances VR100 instance-type virtual-router set routing-instances VR100 interface lt-0/0/0.100 set routing-instances VR100 interface lo0.100 set routing-instances VR200 instance-type virtual-router set routing-instances VR200 interface lt-0/0/0.200 set routing-instances VR200 interface lo0.200
I put lo0.100 and lo0.200 in there to have something to advertise. You’ll see that in a second.
Now, let’s see if we can ping across.
root@TestSRX# run ping 192.168.0.100 routing-instance VR200 PING 192.168.0.100 (192.168.0.100): 56 data bytes 64 bytes from 192.168.0.100: icmp_seq=0 ttl=64 time=1.879 ms 64 bytes from 192.168.0.100: icmp_seq=1 ttl=64 time=3.480 ms <SNIP>
Woot! It works. Now we can treat these new interaces as if they are regular ole Ethernet. Since I’m not ready to try and blog about IS-IS, let’s just use the standard OSPF. I’m not going to go through the steps to configure OSPF, but here’s the routing table after all the interfaces are included.
root@TestSRX# run show route VR100.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.100/32 *[Direct/0] 00:41:33 > via lo0.100 10.0.0.200/32 *[OSPF/10] 00:00:28, metric 1 > to 192.168.0.200 via lt-0/0/0.100 192.168.0.0/24 *[Direct/0] 00:38:21 > via lt-0/0/0.100 192.168.0.100/32 *[Local/0] 00:38:21 Local via lt-0/0/0.100 184.108.40.206/32 *[OSPF/10] 00:01:18, metric 1 MultiRecv VR200.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.100/32 *[OSPF/10] 00:00:28, metric 1 > to 192.168.0.100 via lt-0/0/0.200 10.0.0.200/32 *[Direct/0] 00:41:33 > via lo0.200 192.168.0.0/24 *[Direct/0] 00:38:21 > via lt-0/0/0.200 192.168.0.200/32 *[Local/0] 00:38:21 Local via lt-0/0/0.200 220.127.116.11/32 *[OSPF/10] 00:01:18, metric 1 MultiRecv
Look! OSPF routes! Sweet. Just to keep my OCD at bay, let’s ping from the loopback of one VR to the loopback of the other.
root@TestSRX# ping source 10.0.0.100 routing-instance VR100 10.0.0.200 PING 10.0.0.200 (10.0.0.200): 56 data bytes 64 bytes from 10.0.0.200: icmp_seq=0 ttl=64 time=1.463 ms 64 bytes from 10.0.0.200: icmp_seq=1 ttl=64 time=1.443 ms <SNIP>
Well, look at that. It works again.
Let’s look back at the topic we’re discussing, though. If we use OSPF between the VRs, we need to make sure our routing design allows us to filter routes between the VRs; the risk is that you may wind up having all the routes from each VR advertised to the other. Kind of defeats the purpose, eh? Running BGP between the VRs might be an option that allows you to control what routes go in and out. Statics might be the answer, as well. As long as you can filter the advertisements, you wind up with a pretty elegant solution for sharing routes between VRs.
Marshmallow Peeps questions my way.
I tried something like this earlier this year with STP. It got rave reviews (from my mother), so I figured I try it again.
Below is a list of requirements for configuring a router as a call processor. In a lab or in your head, configure the router to support the features as listed. This isn't a contest or anything like that. If you get it right, a virtual thumbs up is all I can afford to give you. There are some licensing issues for running this stuff in GNS3/dynamips, so I can't help you out on that. I'll just hint that GNS3 and dynamips will bind to real networks and that copies of a compatible IP softphone are available.
Here we go.
- Maximum of 10 DNs
- Maximum of 5 ephones
- DHCP server that provides the appropriate DHCP scope option for getting the phones online
- Phone 1
- Sales Phone A
- Button 1: extension 1001
- Button 2: intercom to phone 3 labeled as "Lackey"
- Pickup Group 3001
- Phone 2
- HR Phone A
- Button 1: extension 1002
- Pickup Group 3001
- Phone 3
- Sales Phone B
- Button 1: extension 1003
- Button 2: monitor button 1 on phone 1
- Button 3: intercom to phone 1 labeled as "Boss" that answers unmuted
- Pickup Group 3002
- Phone 1
- Each department should have its own paging group.
- All phones should be in a paging group for broadcasting emergencies to all employees.
- Call Parking
- 2 call parking DNs
- 1 CP DN should be dedicated to phone 2
- Music on Hold
- MOH should play when a user is on hold or in a park slot
- After hours should be Mon – Fri from 7pm to 7am
- No one should be able to dial 1003 after hours
- No one should be able to dial 1002 any day at any time
I'll get my own answer together and post the consensus result in a few days. In the meantime, let me know how terribly I did.
unlicensed CIPC phones questions my way.
More of my IIUC study notes. As always, feel free to correct. I really need to have a real post, don't I?
show voice port summary
- Shows the voice ports available for use
R1#show voice port summary IN OUT PORT CH SIG-TYPE ADMIN OPER STATUS STATUS EC ============== == ============ ===== ==== ======== ======== == 50/0/1 1 efxs up up on-hook idle y 50/0/1 2 efxs up up on-hook idle y 50/0/2 1 efxs up up on-hook idle y 50/0/2 2 efxs up up on-hook idle y 50/0/3 1 efxs up up on-hook idle y 50/0/4 1 efxs up up on-hook idle y 50/0/5 1 efxs up up on-hook idle y
- An ephone-dn shows up as efxs, so all these are ephone-dns.
- Channels are numbered 0-23; timeslots are numbered 1-24
- Connect to end stations like analog phones and fax machines
- Ground start: New connections started by grounding wires
- Typically used when tied to PBXes
- Loop start: New connections started by sending DC voltage
- Typically used when connecting to analog devices
- Ground start: New connections started by grounding wires
- Call progress tones
- Audible tones to let the user know the status of a call
- Dial tone, busy, call waiting, etc.
- Different in each geographical area
- Audible tones to let the user know the status of a call
- Caller ID
- Identifies the name and number that calls on this line should appear
R1(config-voiceport)#signal loopStart <- Use loopstart signaling
R1(config-voiceport)#cptone PE <- Uses CP tones from Peru
R1(config-voiceport)#station-id name Corporate Fax
R1(config-voiceport)#station-id number 5551212
- Connects to CO or PBX
- A lot of the same configurations as FXS ports
- Two additional to discuss
- dialt-type: DTMF or pulse dialing
- ring: The number of rings to wait before answering; usually 1
- Think of allowing a home user to answer the phone before the fax machine picks up
R1(config-voiceport)#dial-type dtmf <- touch tone
R1(config-voiceport)#ring 3 <- wait 3 rings before answering
Digital Voice Ports
- Unlike analog voice ports, digital voice ports must be configured to function with the network to which they are attached.
- Voice and WAN interface cards (VWICs) provide digital voice port
- show controllers t1
- Framing: defines how to format the frames
- SF or ESF
- Line coding: encodes the signal in a way to maintain sychronization
- AMI or B8ZS
- Clock source: defines who dictates the clocking
- Signaling: channel signaling
- CAS: use ds0-group
- Ports show up as 0/0:1, where 0/0 is the physical port and 1 is the ds0 group
- CCS: use pri-group
- Ports shows up as 0/0:23, where 0/0 is the physical port and 23 is the signaling channel (16 in E1)
- CAS: use ds0-group
R1(config)#isdn switch-type primary-5ess <- If using CCS
R1(config)#controller t1 0/0
R1(config-controller)#clock source line <- get clocking from provider
R1(config-controller)#ds0-group 1 timeslots 1-24 type fxo-loop-start <- Using FXO loopstart signaling
R1(config-controller)#pri-group 1 timeslots 1-24 <- assumes signaling from CCS and ISDN switch-type
- "Routing" for phone numbers
- Tells a voice gateway where to send calls based on dialed number
- Two types dial peers
- POTS: Traditional connections like T1 and analog phone lines
- VOIP: Connections to an IP address
- show dial-peer voice summary
R1(config)#dial-peer voice 1101 pots
R1(config-dial-peer)#destination-pattern 1101 <- This number…
R1(config-dial-peer)#port 0/0/0 <- …is on this FXS port.
R1(config)#dial-peer voice 1102 pots
R1(config-dial-peer)#destination-pattern 1102 <- This number…
R1(config-dial-peer)#port 1/0:23 <- …is on this T1 PRI port.
R1(config)#dial-peer voice 1103 voip
R1(config-dial-peer)#destination-pattern 1103 <- This number…
R1(config-dial-peer)#session target ipv4:10.10.10.1 <- …is at this IP address…
R1(config-dial-peer)#codec g711ulaw <- …and use this codec when you get there.
Here are some more notes from my IIUC studies. As always, corrections requested.
- Broadcasts messages to a group for a one-way communication
- Paging groups are used to limit which phones get the broadcast
- Paging can be unicast or multicast
- Unicast groups limited to 10 members
- Multicast requires mcast support on the network
- Paging configurations can be unicast, multicast, or multiple-group
! Unicast Paging
! When 1044 is dialed, ephone 1 is paged
! Multicast Paging
! When 1045 is dialed, ephone 2 is paged
R1(config-ephone-dn)#paging ip 18.104.22.168 port 2000
! Multiple Group Paging
! When 1046 is dialed, both ephones 1 and 2 are dialed
R1(config-ephone-dn)#paging group 44, 45
- There is a limit of 10 DNs in the paging group.
After-hours Call Blocking
- Allows you to configure time ranges and patterns that cannot be called during those ranges
- Three steps
- Defines days and/or hours that are considered after-hours
- Specify patterns to be blocked
- Create exemptions
R1(config-telephony)#after-hours day mon 18:00 07:00 <- afterhours = 6pm to 7am
R1(config-telephony)#after-hours day tue 18:00 07:00
R1(config-telephony)#after-hours day wed 18:00 07:00
R1(config-telephony)#after-hours day thu 18:00 07:00
R1(config-telephony)#after-hours day fri 18:00 07:00
R1(config-telephony)#after-hours date Dec 25 00:00 00:00 <- Christmas is after hours
R1(config-telephony)#after-hours block pattern 1 91900……. 7-24 <- Pattern index 1 blocks 900 numbers 7day/24hours
R1(config-telephony)#after-hours block pattern 2 91………. <- Pattern index 2 block all long distance after hours
R1(config-telephony)#login timeout 15 clear 18:00 <- Allows logins for entering a PIN for after-hours exemption; times out in 15 minutes and clears at 18:00
R1(config-ephone)#after-hours exempt <- the boss's phone can call anywhere except the 7-24 patterns
R1(config-ephone)#ping 1234 <- Your phone can log in with this PIN for after-hours access
- Phones have to be restarted or reset for the Login key to be enabled.
- It's important to see who is calling international numbers every day at lunch.
- Call Detail Records (CDRs) record who called what number when for how long plus more stuff.
- CME logs CDRs to the logging buffer, syslog, or both.
- Logging buffers clear when a router loses power, but it may be better than nothing. <- Don't do this ever! Get a syslog server!
R1(config)#logging buffer 512000 <- Set the logging buffer size to 512000 bytes
R1(config)#dial-control-mib retain-timer 120 <- Roll records out in 120 minutes
R1(config)#dial-control-mib max-size 100 <- Only keep last 100 records
- Sending to syslog allows you to keep more records
R1(config)#logging 192.168.0.2 <- Log to this server
- Account codes are used for billing.
- Each department or unit can enter a code that appears in the CDR for use later.
- Users press the Acct key when the call is ringing or connected to enter their code.
Music on Hold
- Do I have to explain what MoH is?
- WAV or AU file in flash
- Files must be G.711 or G.729
- G.711 is recommended since it is of higher quality
- Can be delivered via unicast or multicast
R1(config-telephony)#moh piratedmusic.au <- Plays a local audio file as MoH
R1(config-telephony)#multicast moh 22.214.171.124 port 2001 <- multicast the MoH
Here are some more notes from my IIUC studies. As always, corrections requested.
- Allows users to look up names
- Allows names to show up when dialing or receiving a call
- Most phones have a directory button; some have a menu options for the directory
R1(config-ephone-dn)#name Roger Smith
- Directory entries can be added manually
R1(config-telephony)#directory entry 1 1700 Corporate Fax
R1(config-telephony)#directory entry 2 1701 HR Fax
- By default, sorting is done alphabetically by first name.
- Sorting can be changed
- Can be done by the user or through CLI
- User presses CFwdAll button, enters a number, and #; pressing CFwdAll again cancels forwarding.
- CLI forwarding is more flexible
R1(config-ephone-dn)#call-forward busy 1800
R1(config-ephone-dn)#call-forward noan 1800 timeout 25 <- if no answer after 25 seconds
R1(config-ephone-dn)#call-forward max-length 0 <- disabled forwarding
R1(config-ephone-dn)#call-forward max-length 4 <- restricts forwarded number to a length of 4 digits
- H.450.3: A voice gateway redirects the forward to another gateway instead of using the phone as a proxy
- Direct path from originator to destination
- Frees up network resources by keeping path direct
- Keeps latency and jitter down by avoiding long looping paths and a hairpin turn at the phone
- Forwarding patterns can help restrict where calls can be forwarded
R1(config-telephony)#call-forward pattern 1… <- allows forwarding to a 4-digit number starting with 1
- H.450.2: A voice gateway redirects transfers to another gateway instead of using the phone as a proxy.
- The user doing the transfer is dropped from the conversation after transfer is complete.
- Generically, there are two types of forwarding.
- Blind: sends the caller to the number blindly
- Consult: allows you to talk to the endpoint before transferring the call
- CME has three types of forwarding.
- full-blind: blind transfers using H.450.2 or SIP REFER
- full-consult: consult transfers using H.450.2 or SIP REFER if second line is available; if not, fall back to full-blind
- local-consult: Cisco-proprietary method for full-consult
- or -
- Transfer patterns work similarly to forwarding patterns
- Call parking allows a user to retrieve a call from any phone by "parking" the call to an extension.
- The call can be picked up from any phone able to dial that extension.
- Park numbers can be assigned randomly or manually.
R1(config-ephone-dn)#park-slot <- makes this DN a park slot
- Call parking has several options.
- reserved-for dn: Only that DN can use this park-slot
- timeout seconds: Ring the phone phone that parked the call after that many seconds to remind them of the park
- limit count: After that many timeout intervals, drop the call. Not good for customers.
- notify dn [ only ]: Notify that DN when a timeout is reached
- recall: Sends the call back to the original phone when the timeout is reached
- transfer dn: Sends the call to this DN when the timeout is reached
- alternate dn: If the DN in the transfer command is not available, go here
- retry seconds: Try to transfer again after this many seconds
- The phone must be reset for call parking to take effect.
- Allows users to pick up other ringing phones
- Best to use pickup groups so the sales guys don't pick up support calls by accident
- There are three methods to pickup a call.
- Directed pickup: A user picks up a ringing phone by pressing PickUp followed by the target DN.
- Local group pickup: A user picks up a ringing phone in his pickup group by pressing GPickUp then *.
- Other group pickup: A user picks up a ringing phone in another pickup group by pressing GPickUp then the other group number.
- Technically is a speed dial and auto-answer combination
- Intercom button is pressed, which dials a DN bound to another phone; that phone automatically answers on mute.
- The DNs involved usually (?) can't be dialed.
- e.g., A101
R1(config-ephone-dn)#intercom A98 label "Boss"
R1(config-ephone-dn)#intercom A99 label "Lackey"
- Other options
- barge-in: Places existing calls on hold on the other end and barges n
- no-auto-answer: Rings instead of auto answers
- no-mute: Doesn't mute when auto answering. Can you say spying?
More study notes. Correct if wrong, though I hope I get some of it right since I already since I'm an R&S guy. :$
- switchport mode access: This config makes the port an access port that carries the primary and voice VLAN traffic
- switchport mode trunk: This config akes the port a trunk unconditionally, but it will still send DTP messages
- switchport nonegotiate: This config keeps the port from sending DTP messages.
- switchport mode dynamic auto: If the port receives DTP messages, it will become a trunk. If not, it will be an access port.
- switchport mode dynamic desirable: The port actively sends DTP messages trying to become a trunk. This is the default configuration on a Cisco switch.
Cisco IP Phone Boot Process
- Phone connects to an Ethernet switch and gets power if needed
- Switch tells the phone the correct voice VLAN through CDP
- Phone sends DHCP request for its voice VLAN
- DHCP offer includes the TFTP server from which to download the config
- Phone downloads the config from the TFTP server
- Phone contacts the call processing server as dictated in the config file
DHCP Settings on a Cisco Router or L3 Switch
R1(config)#ip dhcp pool MYPOOL
R1(dhcp-config)#network 192.168.0.0 255.255.255.0
R1(dhcp-config)#option 150 ip 192.168.0.20 <– Tells the phone to download the config from this TFTP server
R1(config)#ip dhcp excluded-address 192.168.0.1 192.168.0.100 <– Don't use these IPs when handing out DHCP
Why should you use NTP for a CME setup?
- Phones display correct time
- Voicemails have the correct time
- CDRs are timestamped accurately
- Router logs are timestamped accurately
- Time-based access worked predictably
R1(config)#ntp server 126.96.36.199
R1(config)#clock timezone MYTZ -5 <– Sets the timezone to a zone called MYTZ that's 5 hours behind UTC
I posed the philosophical question on Twitter the other day asking if single trunk links should be in an EtherChannel bundle just in case you need to expand later. I didn’t really expect an answer, but the ever-verbose @WannabeCCIE pointed out (in not so many words) that you should watch your IDBs. What is that?
That’s an interface descriptor block. I admit that I’m not intimately familiar with them, bu they’re data structs in IOS used to keep track of the interfaces on that device. They come in two flavors – hardware and software. HWIDBs usually represent a physical interface but they also represent tunnels, SVIs, PortChannels, subinterfaces, and any other virtual interface that you can configure. The SWIDBs represent the layer-2 encapsulation of each HWIDB, so you’ll see entries talking about Ethernet, HDLC, PPP, etc. That means that every interface you have on a router consumes two IDBs (there are always exceptions). That’s important because each platform and IOS version combination has a limit to the number IDBs that device supports.
If you check out one of Cisco’s pages on IDBs, you’ll see a pretty table showing the limits. The 3640 running 12.4(25b) that I run in my GNS3 lab has a limit of 800 IDBs. That means that I can have 400 interfaces configured at most. That little 800 series router running 12.1T that you still have running at the VP’s house has an IDB limit of 300 or 150 interfaces. The 7200 in the data center running 12.3 can handle 20,000 IDBS or 10,000 interfaces!
If you guessed that you can see your IDBs by typing show idb, then you guessed right. That will show you the IDB limit, how many are being used, a summary table, and a list of all the IDBs with their details. Remember that there may be more interfaces on your device that just physical. You may have an SVI, loopback interface, or even a null or two. These all count towards the limit.
Before you get freaked out and start checking the IDB limits on all your devices, take a breath. I’ve never run into the IDB limit on any device and I’ve never heard of anyone who has. I’m sure someone has, but I don’t remember hearing about any. Think about it for a second. If I took my 3640 and filled it with 4 NM-16ESWs, I’d only have 128 IDBs used (16 ports * 4 modules * 2 IDBs for each port). Don’t forget the null interface and VLAN 1 SVI by default (VLANs take 1; VLAN SVIs take 2 each). That brings the count to 133. Let’s add 100 more VLANs and SVIs on this guy. Now we’re up to 433. How about we put each interface into a channel group of its own. That adds another 128, which is 561. Only 239 more to go.
Unless you’re doing something out of the ordinary, I don’t think the IDB limit will be a problem. Of course, that depends on your definition of “ordinary”.
Send any sort indexes questions my way.
SSH is more than just a shell. You can copy files from and to a server or piece of network gear with it. You can use it to tunnel traffic. Possibly my favorite, though, is to use SSH to run a command on a remote box without interacting with a shell.
One of my biggest pet peeves with IOS (or pretty much any Cisco OS) is the lack of complex filtering. Let’s say I want to look at all the downed ports and interfaces on modules 3 and 6 of my 6509. I can’t easily do that with command from the IOS, but, on my Linux box, I can use multiple grep commands to get exactly what I want really easily. Let’s work through the example, shall we?
To start with, let’s just do a show ip int brief without getting a shell on the switch.
ssh my.switch.com "show ip int brief"
When you run this and give your password, you see the output we’ve all learned to love, and, now that you’ve got it in STDOUT on your Linux box, you can start filtering. Now, let’s use grep to find the downed ports and interfaces on modules 3 and 6.
ssh my.switch.com "show ip int brief" | grep down | grep Ethernet
How about downed ports and interfaces on modules 3 and 6 that not administratively down?
ssh my.switch.com "show ip int brief" | grep down | grep Ethernet | grep -v admin
I’ll stop there, but it can go on and on. Read up on regular expression and/or grep if you don’t know what we’re doing here.
What’s really happening is that we’re taking the output of the command “ssh ….” and piping it (with |) to the command grep. We can send it to whatever command we want, though, so don’t be shy. I’ve actually written several scripts that take output of commands like show int description on a router to generate some reports. When I want to run one of those, I do something like this.
ssh my.switch.com "show int desc" | parseOutput.pl
There’s always a gotcha or two to watch for, isn’t there? I’ve found a couple.
First, your command runs at your privilege level, so, if your user is priv 1, you’re not going to be able to do a show run or reload. You could just ignore security for a bit and set your privilege to 15, but I don’t recommend doing anything like that. Before you say it, you’ll probably have a hard time with enabling as well. You can only run one command at a time, so you would just enable yourself and get kicked off. Not very helpful.
Another problem I see is the lack of public/private key pair support on Cisco devices. On a Linux box, you can copy your keys around, and those are presented in lieu of a password. Since (most) Cisco devices don’t have home directories, there’s no place to drop the keys, and we’re left with just using passwords. Support for this would be nice, but the security problems associated with keep SSH keys and user home directories are probably too much to even think about.
What else? Oh, yeah. The PIX/FWSM/ASA family supports SSH, but it acts differently from the IOS guys. When you run a command through SSH, you actually get an interactive shell with the command already on the CLI for you. This is probably by design; the only thing you can really do from a non-priv prompt is to enable.
Anyway, send any grilling tips questions my way.