Our 206.107.208.0/20 netblock have been dampened numerous times today.
Anyone know why Sprint is announcing the /14?
BGP routing table entry for 206.104.0.0/14, version 5323768
Paths: (2 available, best #1, advertised over IBGP, EBGP)
1239
198.32.136.11 from 198.32.136.11 (144.228.105.1)
Origin IGP, metric 5, localpref 100, valid, external, best
Community: 2548:668
1239
198.32.136.129 from 198.32.136.129 (144.228.105.5)
Origin IGP, metric 28, localpref 100, valid, external
Community: 2548:668
Regards,
Turnando Fuad
NSNet
Hmm.. because it's a Sprint CIDR block? I don't see what's wrong with Sprint
announcing an aggregate of its own CIDR block.
Perhaps I'm failing to parse your message.
-dorian
US Sprint (NETBLK-NETBLK-SPRINT-BLKG)
13221 Woodland Pk. Rd
Herndon, VA 22071
Netname: NETBLK-SPRINT-BLKG
Netblock: 206.104.0.0 - 206.107.255.255
Maintainer: SPRN
Coordinator:
Sprint Network Info & Support Center (SPRINT-NOC) noc@SPRINT.NET
(800)232-6895
Fax- (703)478-5471
Domain System inverse mapping provided by:
NS1.SPRINTLINK.NET 204.117.214.10
NS2.SPRINTLINK.NET 199.2.252.10
NS3.SPRINTLINK.NET 204.97.212.10
ADDRESSES FROM THIS BLOCK ARE NON-PORTABLE
Record last updated on 10-Sep-96.
Database last updated on 21-Nov-97 05:56:08 EDT.
Hmm.. because it's a Sprint CIDR block? I don't see what's wrong with Sprint
announcing an aggregate of its own CIDR block.
Perhaps I'm failing to parse your message.
Sprintlink had assigned us 206.107.208.0/20. We have been trying to figure
out why that netblock was having some flap sessions today when we saw
Sprint's /14 announcement. So we jumped the gun on them and thought they
were the cause :). Apparently, they were dampening the /20 block to the
point that they weren't announcing it. We are still trying to determine
the cause of the flaps as we had only added the null0 static route for
that netblock this morning. And the 5-6 flap sessions today started after
we reset the Sprint BGP session. We are a little baffled as we have a
static BGP config and are not advertising our IGP routes into our BGP. And
we have taken the Null0 static route out for now.
On a related note, would it be possible to spoof BGP announcements and
deliberately cause the flaps? Coincidentally, one of our customers with a
network in that block believed his webserver was attacked earlier today.
He didn't have any tools to sniff out the IP information and all he had
was his Web access log which registered lots of entries for GIF files
without any source addresses. It's a long shot and just a wild guess.
Regards,
Turnando Fuad
NSNet