Nov
26

Here is a small task that illustrates how combining a few technologies may result in interesting solution.

Task:

Configure R1 to send all logging messages to the remote server at the IP address "10.0.0.100". Ensure secure (non-cleartext) and reliable (acknowledged) information delivery.

DO NOT USE:

1) TCP as the transport protocol.
2) IPsec for encryption.
3) Any tunneling technology.

Recent update: do not use BEEP. This seems to be ruled out by "don't use TCP", but worths being mentioned separately. The solutions is supposed to be a "bit" more complicated :)

For simplicity, assume the server to be directly connected to the router via Ethernet. Also, assume the server could be configured in any way to match the router's configuration.

The first person to find the correct solution would win a 100$ Amazon.com gift card. Since tomorrow is a big holiday in the US, we will post the solution and announce the winner somewhere around the coming weekend.

Have a nice Thanksgiving!

----

OK, it looks like I'm getting old after all :) The solution has been found a few hours after I actually made the post! The Winner is: Carl Burkland. Congratulaitons! He was the first to post a working solution. I'm disclosing the comments right now, so you can see other people who came with correct solutions or bright ideas after Carl. Also, see some explanations and comments below.

R1:
logging history debugging
snmp-server engineID remote 10.0.0.100 ABCD12345678
snmp-server group TRAP v3 priv
snmp-server user TRAP TRAP remote 10.0.0.100 v3 auth sha CISCO priv des56 CISCO
snmp-server enable traps syslog
snmp-server host 10.0.0.100 informs version 3 priv TRAP

The idea is combine the following features:

1) Syslog history buffer logging.
2) SNMP traps/informs generation based on syslog messages.
3) SNMPv3 DES encryption for traps/informs.
4) Reliable delivery thanks to informs mechanism.

Of course, using any reliable transport would be too easy ;). Antonio Soares (and later Sorin CONSTANTINESCU) came with an idea of using PPPoE with MPPE and PPP reliable delivery features. While this violates the requirement of not using any tunneling techniques (in this case - L2 inside L2) the idea is really good. The only problem is that I never found the "reliable" PPP to work, particularly with PPPoE :) Looks like you still need good old LAPB encapsulation on serial interfaces to enforce reliable delivery. There is another protocol called "RBSCP" which you could use across unreliable/long-haul links to imporve TCP performance, but this is deserves a separate post.

Other people (e.g. NTllect, Lejoe Thomas – see their comment) correctly suggested using SNMPv3 informs, but some did not provide the complete working configuration. The trick is that in order to get SNMPv3 informs working you need to configure a remote engine ID for the remote server and associate the SNMPv3 user with this ID. Without that, the router will not send any informs! You can easily verify if your configuration is working by doing something like this:

access-list 100 permit udp any any eq 162

R1#debug ip packet 100 dump

Generating some syslog messages, and see if you see packets captured.
After that, use the command show snmp pending to see the pending informs (if any).

Overall I’ve seen a bunch of pretty good answers. Thanks a lot to everyone for participating. Congratulations to winner once again, our sales team will contact you after holidays! Oh yeah, and next time I will try to come with more complicated tasks.

Aug
07

For the sake of simplicity and enabling a wider audience we decided to post our regular CCIE brainteasers to the blog.  The winner will get a coupon worth 10% off the price of any of our training packages for R&S, Security, Voice or Service Provider or a $250 Amazon.com gift card! Note that the 10% off discount can not be used with any other discount code you may already have. Please post your solution under the comments for this blog entry - the first person to post the correct solution is the winner. Make sure you provide the correct email address in your response so we can contact you in the event you won.  On Tuesday (August 12th) we will post the solution and announce the winner.

For today the task is an easy one or at least appears to be ;-) Imagine a simple topology made of 3 switches:

STP topology

All switches are running STP for VLAN123 with SW3 being the root.  Your task is to configure the network in such a way so that SW1 port fa0/13 is the root port and SW1 port fa0/16 is the alternate port for VLAN 123.  Sound easy?  Here are the requirements:

1) Do not change any STP link cost

2) SW3 must remain the root for VLAN 123

3) The port types must be access

4) Do not use the switchport backup interface command

5) Do not try to use SPAN or RSPAN

6) Do not disable STP

Good luck!

The correct solution is:

1) Configure SW2 to tunnel STP BPDUs between SW1 and SW3. This will make SW1 thinking that that SW3 is directly connected with cost 19. STP is still active on SW2, but SW2 considers itself the root.

SW2:
interface FastEthernet 0/13
l2protocol-tunnel stp
!
interface FastEthernet 0/16
l2protocol-tunnel stp

2) Configure SW3 port Fa0/16 with lower STP priority than SW3 Fa 0/13. This will make SW1 select its connection to SW2 as the root port and the other uplink is alternate: both uplinks have equal costs, the upstream port priority is the tiebreaker.

SW3:
interface FastEthernet 0/16
spanning-tree port-priority 64

Below is a summarization of some of the close but not quite correct approaches people submitted:

1) Change interface bandwidth/speeds. This is not allowed, since the requirement was not to change spanning-tree costs.

2) Use dot1q tunnel on SW2 – this was prohibited by requirement to set port modes to access

3) Filter spanning-tree BPDUs coming to SW1 from SW3. This would break the requirement for Fa 0/16 port to be alternate path to root. Aside from that, that would result in STP loop, since this is a circular topology.

4) Disabling STP in SW2 explicitly which is prohibited by the requirements

5) Incorrectly assuming that port-priority on SW1 may influence root port selection

6) One complicated MSTP solution submitted by two people actually works but was submitted after the above solution was posted.  The solution is based on differentiation between regional root and CIST root.  Not the simplest solution but it works.  The two people that posted this solution also deserve credit for their MSTP knowledge.  We'll do a post on MSTP inter-region operations here on the blog in the next few days.

The winner is: "Roman”
 roman.aprias@[snip].com

Subscribe to INE Blog Updates