[afnog] afnog Digest, Vol 49, Issue 24

[Mark Tinka]

On Monday 28 April 2008, Global One Solution wrote:

> I am hoping African ISP are
> building relationship with each other,...

This would be ideal, but isn't happening as fast as we'd all 
like.

Inter-country connectivity isn't rife - most of Africa's 
traffic converges somewhere in Europe or the U.S.

This still needs quite a bit of work, and warrants another 
thread altogether :-).

> and becoming part 
> of larger community.

Starting small with local exchange points and ISP 
associations has been known to help. I've heard of 
initiatives for regional exchange point connectivity, but 
don't have enough information to comment further.

> Can anyone share with us, what is 
> the chosen vendor in most African SP backbone router and
> Edge routers. The reason i m asking, one has to 1st
> project it's core network, and edge so they are not taken
> out of service.

Well, given bandwidth is probably one of the biggest 
operating costs of ISP's in Africa, I don't think it's so 
much a case of having a choice of vendor, as it is what the 
ISP's can practically afford.

Besides, large routers probably wouldn't make much sense if 
the bulk of your traffic is not only international, but is 
constrained by a slow satellite upstream connection.

While on the continent, we found Ciso's 7200-VXR platform to 
be quite sufficient for all our upstream deployments, and 
since that's where most of the customer bandwidth comes 
from/heads to, having the same model or something even 
smaller seemed to work just fine.

I know quite a number of networks still using 2600's or 
3600's - some having migrated to 2800's or 3800's only 
recently, with still quite some headroom.

Given that a 7200-VXR, equipped with an NPE-G1 or NPE-G2 
processor can handle a couple of STM-1's (155Mbps) and a 
couple of full BGP feeds, it should be fine for most 
situations. I don't know that many ISP's in Africa bringing 
down that much capacity on satellite.

If you're looking at competing vendors such as Juniper, 
their J-series routers which, like most of Cisco's 
low-to-mid end routers, including the 7200-VXR, are 
software-based routing platforms, you could have options 
here. But as concerns DoS/DDoS mitigation, it'd still be an 
area of concern.

In the end, it might be quite difficult for *most* ISP's in 
Africa to justify, to their management, why they need 
large, hardware-based platforms, either from Cisco, Juniper 
or any other vendor, when they see less than 100Mbps of 
traffic throughout the year.

> Here is few tips i would like to share. 
>
> 1-   Do not advertised your connected routes (this is the
> /30 or /31 between the PE<>CE),

First, I've seen several arguments for a /31 - but somehow, 
a /30 still helps me sleep at night :-)... I digress.

Not to be pedantic, but if you use PE-CE terminology, you're 
probably referring to an MPLS/VPN environment, in which 
case security considerations could vary, slightly, from 
general global routing table rules.

But assuming you mean the global routing table, not 
advertising /30 point-to-point links doesn't offer that 
much security, I think. For instance, we announce these as 
part of an aggregate, e.g., a /16 allocation - and unless 
you null-route them at your peering borders and edges, you 
couldn't escape them.

>      this will (a) reduce the routing table,...

Not necessarily, because we shouldn't be announcing 
extremely long prefixes in the first place. The general 
practice has been not to announce anything longer than 
a /24 (and even some networks on the Internet don't like 
those anymore).

>      (b) Hard for 
> hackers to launch    attack against the /30 prefix.

They don't need to.

A router, typically, has two or more interfaces - 
traceroutes would indicate which (other) interfaces could 
be bombarded with malicious traffic.

Besides, /30 prefixes are normally transient interfaces. DoS 
and DDoS attackers like to go after web servers and things 
of the sort (which sit much further behind). 

Plus, filtering addresses kills traceroutes and pings, which 
is bad for troubleshooting. Rather you consider rate 
limiting/policing traffic to these addresses.

> 2-   Deploy a ACL that actually protects the control
> Plane of the router, in Cisco they called Receive ACL,
> not sure on other vendors.

Good idea.

But remember ACL's on most of the (Cisco) routers you'll 
find in most of Africa's ISP's networks are processed in 
software, and as such, with enough force, could be used to 
bring the router down, as much as they offer protection.

> 3-   Deploy CoPP (Control 
> Plane Policing)

Another good idea, one I highly recommend.

Again, it's processed in software on Cisco's low-end 
routers, but would offer additional help if it became 
necessary.

One would also do well to protect the management plane, 
i.e., SSH, AAA, SNMP, NTP, e.t.c.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part.
URL: <http://afnog.org/pipermail/afnog/attachments/20080519/cb3f6d6c/attachment-0002.bin>