IGRP default-route and PIX firewall or IGRP deficiencies

[pmoulay]

I do have a case scenario where the private network is running OSPF and IGRP (135.50.x.y network). The core is running OSPF and we are doing mutual redistribution between the IGRP and OSPF domain. When I redistribute a default route from my OSPF network, it does not get propagated to IGRP because IGRP does not understand 0.0.0.0 0.0.0.0. IGRP only understand the ip default-network command.

router igrp 100

netw 135.50.0.0

redist ospf 64 etc

router ospf 64

netw 135.50.0.0 0.0.255.255 area 0

redist igrp subnets etc

ip default-networ 135.50.0.0

I still do not get a default route advertised to my IGRP domain. Any way around that.

[millerv]

Syntax looks correct. What does a debug ip igrp events say ?

[svermill]

Is the route to the network being sucessfully redistributed into IGRP before you try to flag it as a default candidate? If not, did you define a seed metric so that it can be? I will include a link below that was posted on a different forum yesterday. It says that the network must be IGRP *derived* for it to work as a default-network. Meaning that if the router were also running OSPF, there would be no IGRP route in the table due to administrative distance.

Remember that the route can't be forced throughout the IGRP routing domain just by issuing the 'default-network' command. It has to be there already in every routing table where you want it to be effective. You can always define a static route to your intended default network, redistribute static, and then flag as default-network. That may be a little better than trying to redistribute it in from OSPF.

http://www.cisco.com/warp/public/105/default.html

[millerv]

Scott, I was looking at the same bulletin, but it looks like in his igrp network he has the major net defined, So I'm thinking that gets by the origination problem, with ospf on the same router, I'd bet there are some interfaces that fall into that major network

Did you gever get that IS - IS issue fixed?

[svermill]

Vince,

I can't remember which specific IS-IS issue I had. I just know that Cisco Press kept pushing out the publication date for their new book on the subject. I went ahead and read the original RFC, the Integrated IS-IS RFC, the IS-IS chapter in TCP Vol 1, and bought the Cisco CIM on link state protocols. I still apparently need some good old fashion real-world experience but that is hard to come by so far.

I'm not sure I catch your meaning on the origination issue. Could you please rephrase. I was concerned that for some reason the network either wasn't being propogated because he left out the seed metric (more than likely he defined all the metrics in his redist statements but I thought I'd throw it out there) or that OSPF administrative distance was playing a role. Can't really tell how many routers run both protocols. I agree that the major network was defined so the additional default-network statement shouldn't be required. By *origination* I infer the document to say that the route has to be in the active forwarding table and have an "I" code assigned to it.

But honestly I don't really know how IGRP looks at the redistributed routes from OSPF in regard to this situation. Of course, the bulletin to which we both refer always uses static routes as the approach to getting the network into IGRP.

Regards

[millerv]

You were wondering if the low end routers had an IS IS bug. I did a software feature scan and found that the lowest end router tho support IS IS is the 2600 series. Ran into this issue with tunneling some frame relay stuff....

origination just means to me that your default network really exists in your network. I have seen some schemes where it hasn't.

Your right, no sign of default metrics on redist...

I'd like to see all the statements involved...

[svermill]

Phillip,

I was struggling with a default-network issue with EIGRP over the weekend. I may have stumbled on to the answer to your problem as well. You have probably read that the 'ip default-network' command is classful. In deed, you issued the command for the major class b network. However, if your other IGRP routers participate in subnets of that same class b network, chances are those are what is in their routing tables - not a route to the classful network. You MUST have an IGRP CLASSFUL network in your routing table before the default-network will kick in. So since you a splitting the same class b network between two different routing domains and obviously subnetting it, I think you are in a bit of a bind.

As a last resort, bear in mind that although the IGRP protocol doesn't undertand 0.0.0.0, your routers do. You could manually enter a static route to 0.0.0.0 in each router. That could be a chore, depending on the size of your IGRP routing domain.

Now if you could find a way to direct traffic towards a class c address in OSPF, and redistribute that into IGRP, you might do OK?