Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
dwarftosser
Sep 3, 2002

PLEASE LET ME SUCK YOUR COCK, BRETT!

Mierdaan posted:

Can you provide some documentation to back this up? It is my understanding that you cannot send traffic back out over the same physical interface it came in on, but we're talking about logical interfaces when it comes to vlans - not physical.

It will forward to another logical interface. I should have read about your situation more closely.

Anyways, it looks like you have a 255.255.0.0 subnet on your internal interface. Is that intentional?

Adbot
ADBOT LOVES YOU

Mierdaan
Sep 14, 2004

Pillbug

dwarftosser posted:

It will forward to another logical interface. I should have read about your situation more closely.

Anyways, it looks like you have a 255.255.0.0 subnet on your internal interface. Is that intentional?

Yes, our network here is 10.10.0.0/16.

jwh
Jun 12, 2002

Mierdaan posted:

Yes, our network here is 10.10.0.0/16.

How is that supposed to work when the voice network (vlan101) is a subnet of the inside interface's address space?

Wouldn't clients on the inside network just arp for 10.10.7.x hosts? Is the pix doing proxy-arp?

quote:


interface ethernet1 auto
interface ethernet1 vlan101 logical

nameif ethernet1 inside security100
nameif vlan101 Voice security90

ip address inside 10.10.2.1 255.255.0.0
ip address Voice 10.10.7.1 255.255.255.0

atticus
Nov 7, 2002

this is how u post~
:madmax::hf::riker:

jwh posted:

How is that supposed to work when the voice network (vlan101) is a subnet of the inside interface's address space?

Wouldn't clients on the inside network just arp for 10.10.7.x hosts? Is the pix doing proxy-arp?

Yeah that also caught my eye... technically they should both be /24's shouldn't they?

jwh
Jun 12, 2002

atticus posted:

Yeah that also caught my eye... technically they should both be /24's shouldn't they?

You can proxy-arp to fake it (clients in 10.10/16 arp for what they think is local, gateway responds with it's own MAC), but I don't know if proxy-arp is enabled by default on pix interfaces. It probably is, because it's been like that on IOS devices forever, but I don't know for certain. If I had to guess, it's probably enabled by default, and isn't really the problem here.

You also used to be able to set yourself as your gateway in windows, and it would cause the stack to arp for _everything_, which was pretty cool.

Herv
Mar 24, 2005

Soiled Meat

jwh posted:

How is that supposed to work when the voice network (vlan101) is a subnet of the inside interface's address space?

Wouldn't clients on the inside network just arp for 10.10.7.x hosts? Is the pix doing proxy-arp?

If the clients are running a /16 subnet mask they sure as heck won't hit the gateway.

The PIX should be able to figure out things just like a router in regards to 'subnetted' networks. Show route should... show that.

In an earlier post, some guy had overlapping IP 4 subnets (for defining lan to lan VPN) that would have not worked unless he changed his local 10/8 to a 10/24.

Mierdaan
Sep 14, 2004

Pillbug

jwh posted:

How is that supposed to work when the voice network (vlan101) is a subnet of the inside interface's address space?

Wouldn't clients on the inside network just arp for 10.10.7.x hosts? Is the pix doing proxy-arp?

Yeah, I've been wondering about this for a while but wasn't real sure if it was going to cause a problem or not. This scheme was dreamed up by a converged engineer at our phone system implementation partner, I'm gradually getting myself up to speed on how this whole thing works.

jwh
Jun 12, 2002

Herv posted:

If the clients are running a /16 subnet mask they sure as heck won't hit the gateway.
I don't know, do you think so? This is one of those weird cases; on the one hand, if the pix is doing proxy-arp by default (which is probably is), it should respond to arp requests for things on the 10.10.7/24 network, but since the "inside" interface is configured as 10.10/16, I don't know what would happen.

Pretty weird.

Mierdaan
Sep 14, 2004

Pillbug
Well, that's enlightening. I added a static arp entry for 10.10.7.9 (the voicemail server) to one of my boxes, and gave it the PIX's MAC address. I can remote desktop into the voicemail server by IP address now without any problem.

So, this says to me that the PIX wasn't doing proxy-arp by default. Time to read into how to turn it on.

Maneki Neko
Oct 27, 2000

Herv posted:

No sir, it's been either Text Pad, or VI for me for ages.


What OS version is on the 515? Is there a reason to stick with PPTP over L2TP? I have the Vista client using MSCHAP v2 handing auth over to AD via radius, but with L2TP, using PIX 7.2.2(19).

Our current setup is PPTP, L2TP looks like it will do what we want, I'll look at setting it up.

TheCaptain
Dec 5, 2005

It's time to get a little Captain in you!
I'm having a hell of time figuring out this problem with ASA. This is my first time configuring a firewall and I'm a bit in over my head.

I have a 4507 switch and an ASA5510 firewall. The outside interface goes to the internet. The inside interface is a point to point link to the switch. The asa-side IP is 192.168.99.1 and the switch side non-switch-port is 192.168.99.2.

The DMZ is a trunk that goes to the switch carrying the DMZ vlan 120. That vlan is configured with an ip of 192.168.100.1. The switch has a non routed vlan 120 which is assigned to a port. On that port I have a server (192.168.100.9) who's default gateway is the ASA's 192.168.100.1.

I have a routed vlan 20 on the switch that goes out to another server (192.168.0.20). How do I make the DMZ communicate with the server's VLAN. (ping from the 100.9 to the 0.20 and vice versa) I have included a sketch of what I mean.

0.0.0.0 traffic goes to 192.168.99.1.



I'm currently on site and have been hacking away at this for hours. Maybe someone can let me know what I'm missing.

Tremblay
Oct 8, 2002
More dog whistles than a Petco
Captain, post a show ip route from that switch plz. I think the switch is just doing the routing for you, which you don't want.

TheCaptain
Dec 5, 2005

It's time to get a little Captain in you!

Tremblay posted:

Captain, post a show ip route from that switch plz. I think the switch is just doing the routing for you, which you don't want.

Gateway of last resort is 192.168.99.1 to network 0.0.0.0

C 192.168.14.0/24 is directly connected, Vlan34
C 192.168.8.0/24 is directly connected, Vlan28
C 192.168.10.0/24 is directly connected, Vlan30
C 192.168.99.0/24 is directly connected, Vlan40
C 192.168.6.0/24 is directly connected, Vlan26
C 192.168.0.0/24 is directly connected, Vlan20
C 192.168.100.0/24 is directly connected, Vlan120
S* 0.0.0.0/0 [1/0] via 192.168.99.1

I set up a interface vlan on the switch as a last resort to communicate with that server. The IP is 192.168.100.2. Doing that I can ping the server on the DMZ from the switch but not from any other network.

Tremblay
Oct 8, 2002
More dog whistles than a Petco

jwh posted:

You can proxy-arp to fake it (clients in 10.10/16 arp for what they think is local, gateway responds with it's own MAC), but I don't know if proxy-arp is enabled by default on pix interfaces. It probably is, because it's been like that on IOS devices forever, but I don't know for certain. If I had to guess, it's probably enabled by default, and isn't really the problem here.

You also used to be able to set yourself as your gateway in windows, and it would cause the stack to arp for _everything_, which was pretty cool.

Proxy arp on PIX/ASA/FWSM function is based on your NAT config. Any IP address assigned to a physical, logical, or NAT address (nat (int) x.x.x.x) will cause the FW to proxy arp. Static NATs:

static (real_interface,mapped_interface) mapped_address real_address

Tells the FW to proxy arp for mapped_address on interface mapped_interface. Proxy arp can be disabled on a per interface basis as well (sysopt no-proxy-arp <int> [IIRC]).

Tremblay
Oct 8, 2002
More dog whistles than a Petco

TheCaptain posted:

Gateway of last resort is 192.168.99.1 to network 0.0.0.0

C 192.168.14.0/24 is directly connected, Vlan34
C 192.168.8.0/24 is directly connected, Vlan28
C 192.168.10.0/24 is directly connected, Vlan30
C 192.168.99.0/24 is directly connected, Vlan40
C 192.168.6.0/24 is directly connected, Vlan26
C 192.168.0.0/24 is directly connected, Vlan20
C 192.168.100.0/24 is directly connected, Vlan120
S* 0.0.0.0/0 [1/0] via 192.168.99.1

I set up a interface vlan on the switch as a last resort to communicate with that server. The IP is 192.168.100.2. Doing that I can ping the server on the DMZ from the switch but not from any other network.

Yeah see how:

C 192.168.0.0/24 is directly connected, Vlan20
C 192.168.100.0/24 is directly connected, Vlan120

Are connected? Thats bad. That means the switch is routing and not the ASA. Statefull firewalls don't like asymetric routing. Are hosts in the DMZ initiating traffic to the inside or is it only inside hosts initiating connections? Also fix your mask, I don't think you want to have a /16 on Vlan20.

You'll need a static identity nat to get this going (and an ACL), I'm assuming you want the ASA to just route the DMZ and inside nets and not NAT? Assuming that is the case:

static (inside,dmz) 192.168.99.0 192.168.99.0 mask 255.255.255.0
static (dmz,inside) 192.168.100.0 192.168.100.0 mask 255.255.255.0

See my above post on how proxy arp works in case I just reversed what you are trying to do.

Tremblay fucked around with this message at 01:27 on Jul 6, 2007

TheCaptain
Dec 5, 2005

It's time to get a little Captain in you!

Tremblay posted:

Yeah see how:

C 192.168.0.0/24 is directly connected, Vlan20
C 192.168.100.0/24 is directly connected, Vlan120

Are connected? Thats bad. That means the switch is routing and not the ASA. Statefull firewalls don't like asymetric routing. Are hosts in the DMZ initiating traffic to the inside or is it only inside hosts initiating connections? Also fix your mask, I don't think you want to have a /16 on Vlan20.

I want the switch to do all the routing except for the DMZ Vlan. The server in the DMZ is an ISA server and needs to communicate with Exchange which is on the 20 Vlan so connections come in from the internet, to the DMZ through the ISA server which needs to talk to the 20 vlan to get to exchange. Also, I have subnet-zero enabled. That's why I have 192.168.0.0/24.

Tremblay
Oct 8, 2002
More dog whistles than a Petco

TheCaptain posted:

I want the switch to do all the routing except for the DMZ Vlan. The server in the DMZ is an ISA server and needs to communicate with Exchange which is on the 20 Vlan so connections come in from the internet, to the DMZ through the ISA server which needs to talk to the 20 vlan to get to exchange. Also, I have subnet-zero enabled. That's why I have 192.168.0.0/24.

Right, so what I am saying is, since you have a L3 vlan interface on the switch that resides in the DMZ subnet. The switch is currently routing between the .99 and .100 subnets and not the ASA. This is NOT what you want to happen.

TheCaptain
Dec 5, 2005

It's time to get a little Captain in you!

Tremblay posted:

Right, so what I am saying is, since you have a L3 vlan interface on the switch that resides in the DMZ subnet. The switch is currently routing between the .99 and .100 subnets and not the ASA. This is NOT what you want to happen.

Thanks.

Even when the 4507 was not routing, i still couldn't get through. What's the next step?

Tremblay
Oct 8, 2002
More dog whistles than a Petco

TheCaptain posted:

Thanks.

Even when the 4507 was not routing, i still couldn't get through. What's the next step?

You need the static nats I posted above. ASA by default requires a NAT config to get traffic from one interface to another. So basically what we do is write NAT statements that essentially NAT traffic to their original IP addresses. The order of the interfaces is important since it controls which interface proxy ARPs for the subnet or host IP configured. If you flip the interface order you can wind up having the FW and hosts ARPing for the same addresses and that makes a headache.

http://www.cisco.com/univercd/cc/td/doc/product/multisec/asa_sw/index.htm


I've got to head out but I'll check the thread when I get home.

Tremblay fucked around with this message at 01:50 on Jul 6, 2007

TheCaptain
Dec 5, 2005

It's time to get a little Captain in you!

Tremblay posted:

You need the static nats I posted above. ASA by default requires a NAT config to get traffic from one interface to another. So basically what we do is write NAT statements that essentially NAT traffic to their original IP addresses. The order of the interfaces is important since it controls which interface proxy ARPs for the subnet or host IP configured. If you flip the interface order you can wind up having the FW and hosts ARPing for the same addresses and that makes a headache.

http://www.cisco.com/univercd/cc/td/doc/product/multisec/asa_sw/index.htm


I've got to head out but I'll check the thread when I get home.

This is fantastic, I didn't know i could use NAT to route traffic that way. I had to go for the day but I'll pick this up in the morning. I only saw half of your post before so I missed the static entries. Now that I'm home, I'm going to read up on this to speed things up tomorrow.

Thanks again.

Tremblay
Oct 8, 2002
More dog whistles than a Petco

TheCaptain posted:

This is fantastic, I didn't know i could use NAT to route traffic that way. I had to go for the day but I'll pick this up in the morning. I only saw half of your post before so I missed the static entries. Now that I'm home, I'm going to read up on this to speed things up tomorrow.

Thanks again.

Happy to help!

jbusbysack
Sep 6, 2002
i heart syd
What is the typical order in which to tackle the CCNP? I've read that BSCI is a good starting point, but looking for other input.

Korensky
Jan 13, 2004

jbusbysack posted:

What is the typical order in which to tackle the CCNP? I've read that BSCI is a good starting point, but looking for other input.

I think BSCI is the best place to start because the switching exam (BCMSN?) has a lot of content that deals with layer 3 switching/mls and now with the added MPLS content in what was the BCRAN exam you'd be best off having a solid routing foundation to build on. I haven't read the MPLS stuff in the CCNP since I did mine a fair while ago, but you can bet it'll have questions on MPiBGP and PE-CE routing protocols.

BangersInMyKnickers
Nov 3, 2004

I have a thing for courageous dongles

Alright, this is a rough outline of our network as it stands at the moment:


Not pretty. We operate as a division within the university and are very decentralized with about 7 or 8 different remote sites configured in this manner all pointed back to the resources in the main building. Campus networking maintains the links between the sites and the building routers, along with the DHCP server that all our non-static clients are assigned through.

Not controlling our own DHCP registration has been causing more and more administrative headaches as we are growing rapidly (Thanks for setting the Option 81 flag so nothing registers with our DNS servers! :waycool: ) and I really want VPN links between sites so everything looks physically under our control networking-wise. The other consideration is that we don't need web traffic or that other nonsense going across the VPN link when it could be forwarded to the campus building router and be handled from there, so I assume some manner of routing functionality is in order as well.

So if anyone has hardware recommendations of what I should be looking at or a different way of handling this mess, I would appreciate it. Work should be footing the bill for me to get trained to take the CCNA exam in a few months, but I would like to have a long-term plan on how this is going to be corrected before that.

Oh yeah, the firewalls are Juniper Netscreen boxes and I'm not sure what kind of hardware the campus networking guy are running for their routers, but I do know they have a room with some Foundry equipment in it (FastIron Workgroup and BigIron 4000 from what I have seen).

jwh
Jun 12, 2002

Don't know if anybody saw this over on Network World, but apparently Len Bosack has a start-up that's making a little 1U DWDM box. They have CLI manuals online:

http://www.xkl.com/products/product-literature

Looks kind of interesting.

ate shit on live tv
Feb 15, 2004

by Azathoth
code:
rcdsp2851-140>sh ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         10.89.246.140   YES manual up                    up
GigabitEthernet0/1         unassigned      YES unset  down                  up
Serial0/0/0                unassigned      YES unset  down                  down
rcdsp2851-140>
So that is kind of strange.

RMA Ahoy.

Partycat
Oct 25, 2004

Not sure if I asked this before, but this is just a curiosity. Dealing with Cat 3750G-PoE's we occasionally find ports that just won't work at Gig, for no apparent reason. The agonizingly long startup tests show nothing, then we will find a port that will work great at 10/100 but will not negotiate at gig, or work at gig if we lock it down. We tried the obvious, shut/no shut, check log, etc. Nothing comes up, or helps, save for a reload. Obviously once we have a switch full of users operating in a production environment, we can't do this. We're not terribly concerned about it, because it is just one port every so often and we just move the user to an available port, generally. The only thing we could think of is there is some problem with using a 5 Pair punch on 110 blocks, may be causeing a problem. I know it does with PoE devices, you will sort the pairs and get a power error, so we don't do that. We did have this issue show up on one of the mini GBIC ports, however.

Anyone have this happen, or have any ideas? Its just a curiosity...

Arkady
Jun 18, 2004

Off to work!
I'm experiencing the strangest problem.
I have a network with the following configuration:

Router A is not really a router and we don't really care about it at the moment.

The problem is that Router B is not sending RIP updates towards Router A. It is configured with RIP v2, classless, zubnet zero and with no split horizon. The networks configured on Router B are "network 10.31.13.0" and "network 192.168.0.0".
With that config Router B is not sending any updates to Router A. I checked the "debug ip rip" and the RIP is only sending update messages to the 10.31.13.1 interface but not to the 192.168.0.0 interface. I have checked the "show ip protocols" and the 192.168.0.0 network is recognised by RIP. It is also there in the "show ip route" as a locally connected network.

What is even more strange is that if I change the IP of the interfaces between Router A and B to 172.30.x.x it works just fine, sending updates to both interfaces.
All of the above is leading me to believe it has something to do with the class of the networks.. But RIP shouldn't care. It is supposed to send multicasts to the interface that is not on the advertised network. It doesn't build connections or verify that there is someone to receive the multicast. It just sends them out.

I know that this configuration is not a good one. I also know that setting both routers on the same network works fine. This configuration was not made by me and has to stay the same for compatability reasons.

Please tell me I am missing something stupid and that I didn't just stumble onto some strange bug.

Lastly, here is the config I received before doing my tests on it.
code:
!
version 12.4
service config
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!
resource policy
!
ip subnet-zero
!
!
ip cef
!
!
no ip domain lookup
!
!
!
!
interface FastEthernet0/0
 ip address 192.168.4.26 255.255.0.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 ip address 10.31.13.1 255.255.255.0
 duplex auto
 speed auto
!
router rip
 version 2
 network 10.0.0.0
 network 192.168.0.0
!
ip classless
!
ip http server
!
!
control-plane
!
!
line con 0
line aux 0
line vty 0 4
 login
!
scheduler allocate 20000 1000
!
end

ate shit on live tv
Feb 15, 2004

by Azathoth

Partycat posted:

Not sure if I asked this before, but this is just a curiosity. Dealing with Cat 3750G-PoE's we occasionally find ports that just won't work at Gig, for no apparent reason. The agonizingly long startup tests show nothing, then we will find a port that will work great at 10/100 but will not negotiate at gig, or work at gig if we lock it down. We tried the obvious, shut/no shut, check log, etc. Nothing comes up, or helps, save for a reload. Obviously once we have a switch full of users operating in a production environment, we can't do this. We're not terribly concerned about it, because it is just one port every so often and we just move the user to an available port, generally. The only thing we could think of is there is some problem with using a 5 Pair punch on 110 blocks, may be causeing a problem. I know it does with PoE devices, you will sort the pairs and get a power error, so we don't do that. We did have this issue show up on one of the mini GBIC ports, however.

Anyone have this happen, or have any ideas? Its just a curiosity...

The only think I can figure is that you have PoE configured for the ports stuck at 10/100. PoE can't work at GigE speeds. Also is the other device capable of running GigE? Finally if it's only one port sometimes, it sounds like you might have a bad patch between end device and the port. If you have a lovely cable that can't support GigE then it will go down to 100.

In any case I think its a layer 1 problem, and not necessarilly a problem with the switch.

Tremblay
Oct 8, 2002
More dog whistles than a Petco

Arkady posted:

stuff

Exactly what image are you running? Is this in production or in a test lab?

Arkady
Jun 18, 2004

Off to work!

Tremblay posted:

Exactly what image are you running? Is this in production or in a test lab?

I didn't check the version, but it's safe to assume it's a very recent one.
It's in a test lab. We are testing a few things for satellite communication (that's the cloud), with the Router A being a VSAT.

Quickie edit: Just checked the same setup in Netsim and it does exactly the same thing; doesn't send RIP updates to 192.168.0.0 interface, but sends them to 172.31.0.0 without a problem. What is going on! :argh:

Arkady fucked around with this message at 18:58 on Jul 12, 2007

atticus
Nov 7, 2002

this is how u post~
:madmax::hf::riker:

Arkady posted:

I'm experiencing the strangest problem...

...Router A is not really a router and we don't really care about it at the moment....

Then what is it? Are you running routed, gated, quagga on some server if it's not a router? Are they configured properly?

Arkady posted:

The problem is that Router B is not sending RIP updates towards Router A. It is configured with RIP v2, classless, zubnet zero and with no split horizon.

Why why why oh why

Arkady posted:

I have checked the "show ip protocols" and the 192.168.0.0 network is recognised by RIP. It is also there in the "show ip route" as a locally connected network.
What is even more strange is that if I change the IP of the interfaces between Router A and B to 172.30.x.x it works just fine, sending updates to both interfaces.
All of the above is leading me to believe it has something to do with the class of the networks

Not the class. RIPv2 is classless. First of all you need to fix the subnet masks on the 192.168.x.x network. Secondly split horizon is still turned on from looking at your config. Thirdly you need to use major network addresses in your network statements. If you fix both ends of the link to /30's and add the network with

code:
network 192.168.4.0
on both sides, it will happily work. See for yourself.


edit for clarity:

It doesn't even have to be /30's on both sides. You could do /8's or /24's on both sides, but they have to match. Even if you tried to use static routes, your traffic is just getting black holed. If you do a show ip route on router A, you won't see 192.168.0.0/16 as a directly connected network, because your /30 you have on the other side is encompassed in that.

atticus fucked around with this message at 19:27 on Jul 12, 2007

Arkady
Jun 18, 2004

Off to work!

atticus posted:

Then what is it? Are you running routed, gated, quagga on some server if it's not a router? Are they configured properly?

Why why why oh why (no split horizon)

The Router A is a VSAT - Satellite router of sorts. It is configured properly and all I really need is for Router B to send a RIP update to it. The rest should be easy.
I tried testing without split horizon (not shown in this config) because this is a going to be connected to an isolated satellite network, so no fear of loops and such.

atticus posted:

Not the class. RIPv2 is classless. First of all you need to fix the subnet masks on the 192.168.x.x network. Secondly split horizon is still turned on from looking at your config. Thirdly you need to use major network addresses in your network statements. If you fix both ends of the link to /30's and add the network with
192.168.4.0
on both sides, it will happily work. See for yourself.

I know RIP v2 is classless, but for some reason class is coming into the calculation in this case.
Putting the two interfaces on the same network does solve the problem, but that's not the issue. The issue is why doesn't the router advertise RIP to a 192.168.0.0 network. You see, I need to leave the interface of Router A as a /30 and I need to leave the interface on Router B as /16. It works fine for all networks I have tested so far except 192.168.0.0

atticus posted:

edit

I am not sure why do they have to match. The interface can't recognise the other interface's IP and mask. RIP doesn't care for classes or neighbors. It just sends the updates.
As for the masks having to be the same; I'm not sure they do. Ping goes fine between differently subnetted networks. Why do you think it would be a problem?

Arkady fucked around with this message at 19:43 on Jul 12, 2007

Partycat
Oct 25, 2004

Powercrazy posted:

The only think I can figure is that you have PoE configured for the ports stuck at 10/100. PoE can't work at GigE speeds. Also is the other device capable of running GigE? Finally if it's only one port sometimes, it sounds like you might have a bad patch between end device and the port. If you have a lovely cable that can't support GigE then it will go down to 100.

In any case I think its a layer 1 problem, and not necessarilly a problem with the switch.

That is possible. I mentioned using the 5 pair punch which does cause PoE problems on devices trying to draw the power. If it somehow turns it 'on', that may work. I don't think I examined closely an interface exhibiting this behavior enough to notice any comments about PoE. When we find a failure at a workstation, I will test the port, direct attached with a gig enabled laptop, and known good patch, and find that it will flop between "Acquiring address" and "Disconnected". Other times it will sit at disconnected and at some point in time it will appear as being at 100M and start working. Locking the port at 100M, is instant.

However, we did have this issue with one of the mini GBiC ports, for a fibre uplink. Last I checked you can't run power over fibre, so unless the switch becomes confused for some reason that shouldn't play into it.

It hasn't come up recently, and we have been running SEE2 on the IOS, instead of SEB or SED, so maybe it was some odd glitch that is no longer present. It was sort of a running joke that you had to wait 5 minutes for a port test that did not actually seem to "test" anything when we had what would appear to be bad ports, but they may not actually be bad.

ate shit on live tv
Feb 15, 2004

by Azathoth

Partycat posted:


However, we did have this issue with one of the mini GBiC ports, for a fibre uplink. Last I checked you can't run power over fibre, so unless the switch becomes confused for some reason that shouldn't play into it.

It hasn't come up recently, and we have been running SEE2 on the IOS, instead of SEB or SED, so maybe it was some odd glitch that is no longer present. It was sort of a running joke that you had to wait 5 minutes for a port test that did not actually seem to "test" anything when we had what would appear to be bad ports, but they may not actually be bad.

It's very possible that it was a code problem. But I'm still suspicious of why setting the port to 100 would cause it to come up immediately unless PoE was enabled somehow.

Strange. As far as the fiber problem, Cisco devices are pretty specific about what SFP's you use, so if it wasn't that, then it could be any number of things.

jwh
Jun 12, 2002

Arkady posted:

The issue is why doesn't the router advertise RIP to a 192.168.0.0 network.
192.168/16 is classful /24 space, so your third octet needs to play ball with what's configured on the interface. RIPv2 is classless, but it's configuration isn't. The reason your 10/8 and 172.16/16 attempts worked, is because they were accidentally the correct classful mask.

R2#sh run | b router rip

router rip
version 2
network 192.168.0.0
^Z

R2#sh ip proto
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 0 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Automatic network summarization is in effect
Maximum path: 4
Routing for Networks:
192.168.0.0
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 120)

R2#sh ip rip data

R2#sh run int ser1/0
Building configuration...

Current configuration : 88 bytes
!
interface Serial1/0
ip address 192.168.4.26 255.255.0.0
serial restart-delay 0
end

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#router rip
R2(config-router)#network 192.168.4.0
R2(config-router)#exit
*Jul 12 15:21:57.495: RIP: add Serial1/0 to RIP idb list
*Jul 12 15:21:57.499: RIP-DB: redist 192.168.0.0/16(metric 0, last interface Serial1/0) to RIP
*Jul 12 15:21:57.503: RIP-DB: Get redist for network 192.168.0.0
*Jul 12 15:21:57.503: RIP-DB: adding 192.168.0.0/16 (metric 0) via 0.0.0.0 on Serial1/0 to RIP database
*Jul 12 15:21:57.507: RIP-DB: add 192.168.0.0/16 (metric 0) via 0.0.0.0 on Serial1/0 (donot_age)
*Jul 12 15:21:57.511: RIP-DB: Adding new rndb entry 192.168.0.0/16
R2(config)#exit
R2#
*Jul 12 15:22:00.651: %SYS-5-CONFIG_I: Configured from console by console
*Jul 12 15:22:03.675: RIP-TIMER: age timer expired
R2#
R2#sh ip rip data
192.168.0.0/16 directly connected, Serial1/0
R2#

R2(config)#access-list 1 permit any
R2(config)#exit

R2#debug ip pack 1
IP packet debugging is on for access list 1
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#
R2(config)#int ser1/0
R2(config-if)#shut
R2(config-if)#no shut
R2(config-if)#exit
R2(config)#
*Jul 12 15:26:26.427: rip_route_adjust for Serial1/0 going down
*Jul 12 15:26:26.431: RIP: Removing everything from Serial1/0's retrans queue
and stopping the retrans timer.
*Jul 12 15:26:26.435: RIP-DB: flush route of 192.168.0.0/16 on Serial1/0
*Jul 12 15:26:26.435: RIP-DB: Remove 192.168.0.0/16, (metric 4294967295) via 0.0.0.0, Serial1/0(permanent)
*Jul 12 15:26:26.563: RIP-DB: redist 192.168.0.0/16(metric 0, last interface Serial1/0) to RIP
*Jul 12 15:26:26.563: RIP-DB: Get redist for network 192.168.0.0
*Jul 12 15:26:27.047: RIP-DB: redist 192.168.0.0/16(metric 0, last interface Serial1/0) to RIP
*Jul 12 15:26:27.051: RIP-DB: Get redist for network 192.168.0.0
*Jul 12 15:26:27.051: RIP-DB: adding 192.168.0.0/16 (metric 0) via 0.0.0.0 on Serial1/0 to RIP database
*Jul 12 15:26:27.055: RIP-DB: add 192.168.0.0/16 (metric 0) via 0.0.0.0 on Serial1/0 (donot_age)
*Jul 12 15:26:27.059: rip_route_adjust for Serial1/0 coming up
*Jul 12 15:26:27.063: IP: s=192.168.4.26 (local), d=224.0.0.9 (Serial1/0), len 52, sending broad/multicast
*Jul 12 15:26:27.067: RIP: sending request on Serial1/0 to 224.0.0.9

atticus
Nov 7, 2002

this is how u post~
:madmax::hf::riker:

jwh posted:

192.168/16 is classful /24 space, so your third octet needs to play ball with what's configured on the interface. RIPv2 is classless, but it's configuration isn't. The reason your 10/8 and 172.16/16 attempts worked, is because they were accidentally the correct classful mask.

Ah thanks jwh - this is exactly what i was trying so hard to figure out how to say. Again, you're awesome.

Partycat
Oct 25, 2004

Powercrazy posted:

It's very possible that it was a code problem. But I'm still suspicious of why setting the port to 100 would cause it to come up immediately unless PoE was enabled somehow.

Strange. As far as the fiber problem, Cisco devices are pretty specific about what SFP's you use, so if it wasn't that, then it could be any number of things.

The cable tester we are using shows no PoE on these ports being on, unless the switch thinks it is. The fibre issue cleared with a switch reload, so whatever the hardware setup was, seemed to be fine.

Arkady
Jun 18, 2004

Off to work!

jwh posted:

192.168/16 is classful /24 space, so your third octet needs to play ball with what's configured on the interface. RIPv2 is classless, but it's configuration isn't. The reason your 10/8 and 172.16/16 attempts worked, is because they were accidentally the correct classful mask.

I'm still not entirely sure why doesn't the router recognise the 192.168.4.26 interface in the 192.168 /16 network. Are you saying that even though the network is /16, the interface is being recognised with the /24 mask?
Also, what debug command did you use?
Still, the solution you suggested works perfectly. Thank you very much.

Arkady fucked around with this message at 22:48 on Jul 13, 2007

Adbot
ADBOT LOVES YOU

jwh
Jun 12, 2002

Arkady posted:

I'm still not entirely sure why doesn't the router recognise the 192.168.4.26 interface in the 192.168 /16 network. Are you saying that even though the network is /16, the interface is being recognised with the /24 mask?
Also, what debug command did you use?
Still, the solution you suggested works perfectly. Thank you very much.

Well, I'm no expert, particularly on RIP, but from what I was able to test in a lab, the reason IOS didn't pick up on the fact that you had an interface covered by the 192.168.0.0 statement, is because the RIP configuration is approaching things with a classful mentality. This seems to make a certain sense if you consider that RIPv1 was a classful protocol, and maybe for historical reasons, the IOS configuration was never retrofitted.

So in other words, it looks to me like IOS uses the RIP network statement along classful boundaries. Even though your interface is technically 'covered' by the larger supernet of 192.168.0.0/16, IOS is considering 192.168.0.0 classfully, which would match the 192.168.0 portion of the network, because 192.168 is part of class C or /24 classful address space.

That's my theory anyway, it seems to be true, even if it is a little brain-dead on the part of IOS.

Debugging commands were 'debug ip rip event' and 'debug ip rip database' I think, and then the 'debug ip packet' example that's included in the text I wrote. Be careful with debug ip packet, because I have successfully killed production devices with it.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply