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.

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.

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

FXS Ports

Here are some more notes from my IIUC studies.  As always, corrections requested.

Paging

• 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
R1(config)#ephone-dn 44
R1(config-ephone-dn)#number 1044
R1(config-ephone-dn)#paging
R1(config-ephone-dn)#exit
R1(config)#ephone 1
R1(config-ephone)#paging-dn 44

Here are some more notes from my IIUC studies.  As always, corrections requested.

Local Directory

• 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 1
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

R1(config-telephony)#directory last-name-first

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 Configuration
**

• 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

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.

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?