New ISP to market, BCP 38, and new tactics
Although I've posted to this list before, I don't want to waste your time. This is an ops question, so I'm looking for direction, off-list if necessary. We are a *very* small I-SP, and am just now being put in the position to be a backup transit for a client. Currently, our 'upstream' advertises our route for us, 208.70.104.0/21 from my AS 14270 (SBE96-ARIN). As I've wanted to do this myself for some time, the upstream has had issues allowing me to do so. I've also been advertising 2607:f118::/32 via BGP peering to kind people who have been sensitive to the lack of my 'upstream's' inability to provide me with native access. Now, I am about to force my 'upstream' to allow me to bring my advertisement (v4) back to me, I would like off-list feedback of any/all documentation that I should be aware of regarding filtering. I've proven that my 'upstream' doesn't do pull-up routes, doesn't filter BOGON, and given that they have no clients other than myself that have their own IP space, most likely is not capable of doing anything beyond a simple peering session. I've done much research on RPSL, BCP 38, and other basic filter methods (and from a systems standpoint, I always follow an allow,allow,default-deny approach) , and I am willing to follow all standards and recommended practises to ensure compliance with current Internet standards. Although we are small with minimal resources, I feel that touching this list is my best approach to ensure that when I do begin advertising routes, I conform to the most practical, realistic and best current common standards regarding IPv4 route advertisement and filtering. I hate being a 'rat', so I won't state who does what for AS14270 (on the v4 side of things). I have a 100Mbps fibre link from Cobourg Ontario, to _provider_ in 151 Front Toronto. My 'new' connection (which I control), is a direct link to Hydro One. I am open to bandwidth/connection options regarding this feed to Toronto, if you are commercially inclined, Thanks, Steve
For all the kind folk who have been asking how my project is going, I'll summarize here. - I've enabled strict uRPF filtering on all interfaces that I am certain what the source will be. - I've implemented a mix of loose uRPF combined with ACL's on interfaces that I know have multi-homed clients - On all interfaces that run the risk of blocking traffic by accident, I've implemented strict inbound ACL's for known-bad (combined always with Team Cymru BGP learnt bogons), and with logging counter ACLs for all other traffic. After a couple more days, I should be able to focus more strictly on these interfaces - I've made significant changes to my 'core', moving from static routes to an iBGP mesh over OSPF learnt loopbacks. This will allow me to implement a couple of host-based routing daemon boxes for the easy insertion of sinkhole routes in the event of significantly bad behaviour. With my scripting knowledge, preparing a recommended sinkhole route for insertion, ready for admin approval will be easy, and so will having the route removed automatically (or manually) if the attack has ceased. I like the idea of traffic flowing to a host-based machine to null as opposed to null'ing it on the router, as (from what I can tell) it will make it easier to track the flow of the problem ingress and egress - Currently, (as I write), I'm migrating my entire core from IPv4 to IPv6. I've got the space, and I love to learn, so I'm just lab-ing it up now to see how things will flow with all iBGP v4 routes being advertised/routed over v6. The division of the v6 space still overwhelms me, so I guess I'll do what someone else stated in another thread if I mess this one up: go to ARIN for another 1000 /32's :) (no, I'll learn from my mistake, and be ready for next one) Cheers, and thanks! Steve
On 4/02/2009, at 2:33 PM, Steve Bertrand wrote:
- Currently, (as I write), I'm migrating my entire core from IPv4 to IPv6. I've got the space, and I love to learn, so I'm just lab-ing it up now to see how things will flow with all iBGP v4 routes being advertised/routed over v6.
Don't advertise v4 prefixes in v6 sessions, keep them separate. If you do, you have to do set next-hops with route maps and things, it's kind of nasty. Better to just run a v4 BGP mesh and a v6 BGP mesh. -- Nathan Ward
Nathan Ward wrote:
On 4/02/2009, at 2:33 PM, Steve Bertrand wrote:
- Currently, (as I write), I'm migrating my entire core from IPv4 to IPv6. I've got the space, and I love to learn, so I'm just lab-ing it up now to see how things will flow with all iBGP v4 routes being advertised/routed over v6.
Don't advertise v4 prefixes in v6 sessions, keep them separate.
If you do, you have to do set next-hops with route maps and things, it's kind of nasty.
Better to just run a v4 BGP mesh and a v6 BGP mesh.
Ok. I've been having problems with this. What I was hoping for (even though I'm testing something that I know won't work) is that I can break something so I could push v4 traffic over a v6-only core. Is there _any_ way to do this (other than NAT/tunnel etc)? Steve
On 4/02/2009, at 2:43 PM, Steve Bertrand wrote:
Nathan Ward wrote:
On 4/02/2009, at 2:33 PM, Steve Bertrand wrote:
- Currently, (as I write), I'm migrating my entire core from IPv4 to IPv6. I've got the space, and I love to learn, so I'm just lab-ing it up now to see how things will flow with all iBGP v4 routes being advertised/routed over v6.
Don't advertise v4 prefixes in v6 sessions, keep them separate.
If you do, you have to do set next-hops with route maps and things, it's kind of nasty.
Better to just run a v4 BGP mesh and a v6 BGP mesh.
Ok. I've been having problems with this.
What I was hoping for (even though I'm testing something that I know won't work) is that I can break something so I could push v4 traffic over a v6-only core.
Is there _any_ way to do this (other than NAT/tunnel etc)?
MPLS - "The MP is for Multi Protocol!" Otherwise, no, you don't get to use IPv6 addresses as next hops for IPv4 routes, which I think is what you're asking to do. Run IPv4 and IPv6 in parallel, iBGP for v4, iBGP for v6. Same for eBGP to peers/customers. Running v4 and v6 in one BGP session is weird and is asking for confusion, IMHO. You get the same with OSPF - you run OSPFv2 and OSPFv3 in parallel. -- Nathan Ward
On Wednesday 04 February 2009 09:51:16 am Nathan Ward wrote:
You get the same with OSPF - you run OSPFv2 and OSPFv3 in parallel.
Suffice it to say that some vendors are already implementing 'draft-ietf-ospf-af-alt-06.txt', which allows OSPFv3 to handle multiple address families, including IPv4. But this still runs over an IPv6 link. I'd still recommend running IPv4 and IPv6 IGP's separately, unless the IGP integrates both protocols, as in the case of IS-IS. Cheers, Mark.
On Tue, Feb 3, 2009 at 5:43 PM, Steve Bertrand <steve@ibctech.ca> wrote:
What I was hoping for (even though I'm testing something that I know won't work) is that I can break something so I could push v4 traffic over a v6-only core.
Is there _any_ way to do this (other than NAT/tunnel etc)?
If you can push v4 over it (other than through a NAT/tunnel/etc.), then it's not a v6-only core :-) The real question is whether you're going to route natively in v4, or do a v4-in-v6 tunnel of some sort, or a v4-in-Layer2-in-v6 tunnel of some sort, or do NAT, or use MPLS as a Layer 2ish core. If you're doing MPLS, you'll need to figure out if you can run _it_ with purely v6 gear supporting it, or whether you'll need to run v4 to make all of your MPLS vendors happy, but that doesn't need to be publicly routable v4 carrying the entire Internet's routing tables on it; you can leave the Internet inside a large MPLS VPN if you want. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Agreed. Keeping it separate works very well. Can be the same interface sure... but do it as a separate session. ...Skeeve -----Original Message----- From: Nathan Ward [mailto:nanog@daork.net] Sent: Wednesday, 4 February 2009 12:40 PM To: nanog list Subject: Re: [Update] Re: New ISP to market, BCP 38, and new tactics On 4/02/2009, at 2:33 PM, Steve Bertrand wrote:
- Currently, (as I write), I'm migrating my entire core from IPv4 to IPv6. I've got the space, and I love to learn, so I'm just lab-ing it up now to see how things will flow with all iBGP v4 routes being advertised/routed over v6.
Don't advertise v4 prefixes in v6 sessions, keep them separate. If you do, you have to do set next-hops with route maps and things, it's kind of nasty. Better to just run a v4 BGP mesh and a v6 BGP mesh. -- Nathan Ward
Skeeve Stevens wrote:
Agreed. Keeping it separate works very well. Can be the same interface sure... but do it as a separate session.
Yeah, that's what I thought, and that is exactly what I've been doing thus far. I was hoping to have a v6-only core, but in order to get the current project done, I'll have to stay with your (and Nathan's) recommendation. I'm not ready for MPLS (but I am interested in the theory of it's purpose), so when I'm done what I'm doing now, I'll look at it. At that time, if implemented, I'll be the most complex, smallest ISP in Canada ;) This has been an awesome journey, and I've learnt an immense amount via all of the recommendations, reading and exercising. Thanks guys, Steve
On Wednesday 04 February 2009 10:10:02 am Steve Bertrand wrote:
I'm not ready for MPLS (but I am interested in the theory of it's purpose), so when I'm done what I'm doing now, I'll look at it.
Well, having a v6 core will prevent from you running MPLS, as a v6 control plane for MPLS is not yet implemented by the vendors today. A draft for this is already out, though - 'draft-manral- mpls-ldp-ipv6-02'. Cheers, Mark.
participants (5)
-
Bill Stewart -
Mark Tinka -
Nathan Ward -
Skeeve Stevens -
Steve Bertrand