BGP Route Reflector Update Groups (technical details)
One of the readers of my BGP Route Reflectors article spotted an “obvious deviation from how we always though the route reflectors work”:
An IBGP route received from a route-reflector client is sent to all IBGP peers, including the client from which it was received.
A quick lab test confirmed the validity of my claims: a BGP route reflector does send an update back to the client from which it was received (and it’s perfectly legal according to the updated BGP Route Reflector RFC).
Another green initiative from Cisco Systems
Cisco has unveiled numerous green solutions in the last few months, including energy-saving ASR 9000 router and GreenWise initiative. Now they went a step further and implemented some of the old energy-efficient wireless technologies, proving that you don’t always need new technologies to address the energy efficiency (see also Myth #8 in Top 10 Myths about Sustainability).
Generating layer-2 broadcast from a regular IP packet
The Wake-on-LAN discussion we had a while ago brought us nowhere; there's simply no way to generate UDP packets on the router. I thought I could use Application Performance Monitor's Tcl scripts to generate the packet, but it looks like APM has been removed from recent IOS releases (and it's not clear whether you can use APM without a peer router).
The discussion nonetheless had an interesting side effect. Robert Turnšek sent me an interesting trick: with static ARP you can generate layer-2 broadcasts with a layer-3 unicast packet.
Ah, the wonderful quoting process
Network World just published an article on LISP, including a quote attributed to Geoff Huston:
LISP relies on tunneling, and tunneling is not 100% perfect. At times, the tunnel passes a packet that's too big and it disappears without a trace to the sender or the recipient…That's really bad.
We all know what can go wrong with the tunnels: a combination of:
- MTU setting on a core link that is too low to accomodate tunnel envelope+payload with
- Tunnel headend that cannot respond to Fragmentation needed ICMP message.
Rate-limiting Inbound Traffic on DSL
Julian is faced with an interesting challenge:
In the real world, many customers using DSL solutions have their Internet connection disrupted by one internal user performing a large download. On a typical DSL solution, implementing quality of service on outbound traffic is trivial (you can use PQ, CBWFQ, policing or shaping). However, how does one rate-limit inbound traffic in a sensible fashion? Turnkey solutions like packeteer allow inbound classes of traffic like HTTP to be rate limited per flow by dynamically changing window sizes.
Cisco IOS has three basic QoS mechanisms: queuing, shaping and policing. It cannot intercept a TCP session and slow it down by reducing its window size (like PacketShaper).
ADSL overhead
Yesterday I’ve described the difference between line rate and bit rate (actually physical layer gross bit rate and physical layer net bit rate). Going to the other extreme, we can measure goodput (application-level throughput), which obviously depends on multiple factors, including the TCP window sizes and end-to-end delays. There are numerous tools to test the goodput from/to various locations throughout the world (speedtest.net worked quite nicely for me) and you’ll soon discover that the goodput on your DSL line differs significantly from what the ISP is advertising.
Line rate and bit rate
Rajendra had an interesting problem:
Recently I got confused with the term line-rate. Is it the packets being switched across the switch fabric or control packets destined to the protocol tasks or both or something else?
The line rate is a physical layer term that has nothing to do with the line cards or switching fabrics. It indicates the actual speed with which the bits are sent onto the wire (and is thus also known as physical layer gross bit rate). The data transfer rate (commonly known as bit rate) is the transfer rate offered by the physical layer to the data link layer. If you want to be precise, you should call it physical layer net bit rate.
Bandwidth allocation with class-based weighted fair queuing (CB-WFQ)
Sebastian sent me an interesting question:
I have read that we can only use 75% of the bandwidth for the custom queues as 25% is reserved for the keepalives and routing protocol updates. If I want to set 50% of bandwidth for a particular queue should it 50% of the total bandwidth or 50% of the available 75% of the bandwidth?
Before going into the details, it’s important to remember that the WFQ (CB-WFQ is only a mechanism to sort packets into output queues) uses relative ratios (percentages) between queues to determine which packet to send (the absolute bandwidths are used just to compute the ratios).
Over a million page views
Blocking rogue DHCP servers
The reader who was concerned about making a loop while connecting a switch to itself was also facing “customer-installed” DHCP servers in his LAN. He wrote:
Some users have installed their own Linksys routers and plug our cable in router's LAN ports, so there is DHCP servers fight in our LAN. How can I sort this out (I cannot physically find the location of the Linsys routers)?
The ideal solution is DHCP snooping (assuming your switch supports it), well documented on www.cisco.com. The basic configuration takes only a few minutes: