|
Prev: bgp anycast addressing
Next: IP CLASSLESS not working
From: Dan Lanciani on 6 May 2008 16:27 In article <al0Uj.39446$Bb3.28512(a)trnddc01>, fjames(a)levitjames.com (Fletcher James) writes: | Based on numerous tests, I have come to the conclusion that the | router/switch on Verizon's side is totally spoof protected: It will not | respond to an ARP query unless the source address is one of the 61 addresses | assigned to us You could always add a static arp entry for Verizon's gateway on your end and proceed with option D as I indicated. Of course, if they change their MAC address you will lose connectivity until you adapt. | (we've tried .2 and also tried assigning 10.1.1.1 to the | outside of the router, and giving a static route to our gateway.) In one | case, .2 worked briefly -- probably because we had just swiched over, and it | had an association of our MAC address with a valid IP. Possibly there had been an incoming packet to which your router had responded as a proxy. That would not look spoofed since the address would be in your range, and in any case your router would have picked up the MAC address of Verizon's router in the process. Dan Lanciani ddl(a)danlan.*com
From: Fletcher James on 6 May 2008 13:13 It is really a pretty wild situation. There appears to be not a single person in the FIOS business office or tech staff who knows ANYTHING. They can only read scripts and fill in forms which have been provided to them. I will definitely be trying to find some less-formal way way into the organization, or looking to see if there's anyone else who has dealt with this problem. Based on numerous tests, I have come to the conclusion that the router/switch on Verizon's side is totally spoof protected: It will not respond to an ARP query unless the source address is one of the 61 addresses assigned to us (we've tried .2 and also tried assigning 10.1.1.1 to the outside of the router, and giving a static route to our gateway.) In one case, .2 worked briefly -- probably because we had just swiched over, and it had an association of our MAC address with a valid IP. In that configuration, we could route in/out of our network, but couldn't ping from the router to the gateway. Once that timed out, we were blocked, again. We have one remaining option ("OPTION B", in my original post) which is where I think we will end up for the medium term: We will route & NAT 70.x.x.66-.126 on the outside to 10.0.0.66-.126 on the inside. Then, we will NAT again in our ISA server to our LAN and Service Zone addresses. Our VideoTeleconference units, outside the ISA server, can be told that their inside a NAT which is not H.323-aware, and they will work just fine. While we may need to make additional adjustments to a couple of other devices, there is ONE upside advantage to this: once we've got it working, none of the inside hosts will need to be aware of their public IP addresses. It also means that if the router falls back to the T1 line, or we switch ISPs, this will be almost totally transparent to everybody (the VTCs will need to have us adjust "IP Address to Show in Global Phone Book.") "Merv" <merv.hrabi(a)rogers.com> wrote in message news:dc0643b6-7a75-43b6-9560-3739aab37979(a)p25g2000hsf.googlegroups.com... > What is bit strange here is that of having a service were Verizon > dishes out a /26 which is beyond anything a normal residence would > require unless it is a multi-unit dwelling. This really is a an > business Internet service offering but it certainly appears that it is > not being supported as such. > > Unfortunately teh OP does not have access to a Verizon SE or account > manager. If I were him I would write to the President of Verizon and > request to be directed to someone in the Verizon organization who can > address this business issue. >
From: Merv on 4 May 2008 16:26 1. It appears that the router in question is using a Fast Ethernet interface facing the FIOS ONT. If this is in fact the case then an ip unnumbered command will be rejected on a multi-access interface. ip unnumbered can only be used on point-to-point serial interfaces. 2. The following static routing construct is viable: ip classless ip route 0.0.0.0 0.0.0.0 70.x.x.1 ip route 70.x.x.1 255.255.255.255 FastEthernet0/1 Option D would probably work but it is definitely a cludge. The suggestion by other responders to approach Verizon to see if they will provide a /30 or /31 for the FIOS link would definitely be worthwhile pursuing. However be forewarned that if Verizon has not planned for this "feature", it will impact their service provisioning systems and they will less inclined to provide what you are looking for - i.e a /30 for the FIOS link.
From: Merv on 6 May 2008 13:41 Do you need use of all 61 available address ? Becuase another option that one of the other responders proposed was to put part of the space on the outside interface and part on the inside like so int fa 0/0 description inside LAN interface ip addr 70.x.x.98 255.255.255.224 ! default gateway int fa 0/1 description outside interface facing Verizon FIOS ONT ip addr 70.x.x.66 255.255.255.224 ip proxy-arp ! to answer ARP requests from 70.x.x.1 ip classless ip route 0.0.0.0 0.0.0.0 FastEthernet0/1 70.x.x.1 You can use small block on outside and then add secondary address blocks to inside if you want to go to the bother
From: Trendkill on 6 May 2008 13:54
On May 6, 1:41 pm, Merv <merv.hr...(a)rogers.com> wrote: > Do you need use of all 61 available address ? > > Becuase another option that one of the other responders proposed was > to put part of the space on the outside interface and part on the > inside > > like so > > int fa 0/0 > description inside LAN interface > ip addr 70.x.x.98 255.255.255.224 ! default gateway > > int fa 0/1 > description outside interface facing Verizon FIOS ONT > ip addr 70.x.x.66 255.255.255.224 > ip proxy-arp ! to answer ARP requests from 70.x.x.1 > > ip classless > ip route 0.0.0.0 0.0.0.0 FastEthernet0/1 70.x.x.1 > > You can use small block on outside and then add secondary address > blocks to inside if you want to go to the bother Yes, except you would need to ensure Verizon adds a route (or turn up a protocol) to ensure that they know how to get back into the second half of your range. They would also need to turn up a secondary address, as .98/27 doesn't include .1 which is the gateway. You could turn up .68/30 with .69 as their secondary IP, .70 as your router, and then .96/27 on the inside interface. You'd lose .71-.95 unless you want to subinterface the router's connection back to the internal switch and trunk a /29, /28, and /27 instead. Although since Verizon doesn't seem to be able to do anything but transfer your calls, they probably won't turn up a secondary interface (even if its in your address range), and most likely will not add a static route for those subnets. May be worth a call though..... |