I have a question about the subnet size for BGP peers. Typically when we
turn up a new BGP customer we turn them up on a /29 or a /30. That seems to
be the "norm".
We connect to many of our BGP peers with ethernet. It would be a simple
matter to allocate a /24 for connectivity to the customer on a shared link.
This would help save on some address space.
My question is, is this in general good or bad idea? Have others been down
this path and found that it was a bad idea? I can see some of the pothols on
this path (BGP session hijacking, incorrectly configured customer routers
etc). These issues could be at least partially mitigated. Are there larger
issues when doing something like this or is it a practical idea?
What is your access network? Do you have a switch port per customer?
If so, look in to private VLANs on Cisco, or whatever similar feature exists for your vendor.
/29's here for everyone.... great for troubleshooting and any future
additions typically required...
Imagine two of your clients are competitors, they probably don't want to be on the same IP range. And yes, when you sell your service to several customers, you don't want one of them blowing up all the other's SLA.
IXs use /24, as far as I know, and peers connected there can usually use md5 password if they want to. But in that case, some troubles like arp broadcast storm could happen, coming from any of the connected network.
I guess it's not the same level of service, but I agree, many /30 or /29 are a big loss of addresses.
It reminds me GLBP with two gateways: on 10.0.0.0/29, you got
10.0.0.0 : network
10.0.0.7 : broadcast
10.0.0.1 : gw1
10.0.0.2 : gw2
10.0.0.6 : virtual gw
only 3, 4 and 5 for other equipments.
Who knows any other good way to lose IP addresses?
Jim Wininger a �crit :
So what is wrong with a /31? We use /30s but if you are short on IP space, look at using /31 rather than /30 links. Cuts your space usage in half.
If I remember correctly, the BIG problem with using /31s when they first became "legal" was to decide if the customer still gets the higher numbered IP address (or you the lower one), or if you still get the ODD number. No kidding, it is a problem for some!
Where you are on ethernet, use a seperate 802.1q vlan per customer and have your switch give the customer untagged packets. If you have downstreams in your COLO, and either free or as a paid service, offer to setup private vlans in your switch for any pair or group of customers that need to also connect to each other privately for whatever they are doing. In that latter case, they will be getting tagged packets but their routers or switches should have no problem dealing with them.
We don't charge for physical crossconnects, so this has saved us having to do physical crossconnects between customers, and has saved customers router ports.
I know how to not lose them:
int lo30
ip address 192.168.0.1 255.255.255.0
int gi2.10
encap dot1q 10
desc cust 1
ip address unnumbered lo30
int gi2.11
encap dot1q 11
desc cust 2
ip address unnumbered lo30
ip route 192.168.0.2 255.255.255.255 gi2.10
ip route 192.168.0.3 255.255.255.255 gi2.11
etc. Now you can have one customer per vlan but still have them share the same IP subnet. This works with vlan interfaces as well.
I don't remember if you have to do local-proxy-arp or not, but if you're running bgp you could always do next-hop-self to be sure it hops via the gateway.
I did remember that this is identical to the behaviour described in RFC3069.
Shared link for BGP connectivity is a bad idea. Imagine that one of your customer leave proxy-arp on his interface, or imagine that he makes a Layer2 loop. Then all other customers will be affected. Usually a customer with BGP is on another level, so a gain of some IP's doesn't worth the trouble IMHO.
/31's are only defined for point-to-point links.
Ethernet isn't considered PtP in general..
Many devices won't accept a /31 on anything but a PtP WAN media type link.
(or not at all).